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1.  Introduction 

Nested  transaction  systems  have  been  explored  in  a  number  of  recent  research  projects  (e.g., 
see  [8,  23,  21,  1,  7])  as  a  means  for  organizing  computations  in  distributed  systems.  Like 
ordinary  transactions,  nested  transactions  provide  a  simple  construct  for  masking  the  effects  of 
concurrency  and  failures.  Nested  transactions  extend  the  usual  notion  of  transactions  [3]  to 
permit  concurrency  within  a  single  transaction.  They  also  provide  a  greater  degree  of  fault- 
tolerance  by  isolating  a  transaction  from  the  failures  of  its  descendants. 

In  distributed  systems,  various  factors,  including  node  crashes  and  network  delays,  can  result 
in  orphan  computations — subcomputations  that  continue  to  run  even  though  their  results  are  no 
longer  needed.  For  example,  ir  the  Argus  system  [8],  a  node  making  a  remote  request  may  give 
up  because  a  network  partition  or  some  other  problem  prevents  it  from  communicating  with  the 
other  node.  This  may  leave  a  process  running  at  the  called  node;  this  process  is  an  orphan.  The 
orphan  runs  as  a  descendant  of  the  transaction  that  made  the  call.  Since  the  caller  gives  up  by 
aborting  the  transaction  that  made  the  call,  the  orphan  will  not  have  any  permanent  effects  on  the 
observed  state  of  the  shared  data. 

As  discussed  in  [9,  16, 17],  even  if  a  system  is  designed  to  prevent  orphans  from  permanently 
affecting  shared  data,  orphans  are  still  undesirable,  for  two  reasons.  First,  they  waste  resources: 
they  use  processor  cycles,  and  may  also  hold  locks,  causing  other  computations  to  be  delayed. 
Second,  they  may  see  inconsistent  states  of  the  shared  data.  For  example,  a  transaction  might, 
read  data  at  two  nodes,  with  some  invariant  relating  the  values  of  the  different  data  objects.  If 
the  transaction  reads  data  at  one  of  the  nodes  and  then  becomes  an  orphan,  another  transaction 
could  change  the  data  at  both  nodes  before  the  orphan  reads  the  data  at  the  second  node.  This 
could  happen,  for  example,  because  the  first  node  learns  that  the  transaction  has  aborted  and 
releases  its  locks.  While  the  inconsistencies  seen  by  an  orphan  should  not  have  any  permanent 
effect  on  the  shared  data  in  the  system,  they  can  cause  strange  behavior  if  the  orphan  interacts 
with  the  external  world;  this  can  make  programs  difficult  to  design  and  debug. 

Several  algorithms  have  been  proposed  to  prevent  orphans  from  seeing  inconsistent 
information.  Early  work  in  the  a^a  includes  [19],  which  describes  algorithms  for  detecting  and 
eliminating  orphans  that  arise  l coarse  of  node  crashes.  Nelson’s  work  did  not  assume  an 
underlying  transaction  mechanism,  :t  was  difficult  to  assign  simple  semantics  to  abandoned 
computations.  Recent  work  [24, 9,  16,17]  has  studied  orphans  in  the  context  of  a  nested 
transaction  system,  in  which  an  abandoned  computation  can  be  aborted,  preventing  it  from 
having  any  effect  on  the  state  of  the  system.  The  goal  of  the  algorithms  in  [24,  9,  16,  17]  is  to 
detect  and  eliminate  orphans  before  they  can  see  inconsistent  information. 

1.1.  New  Results 

In  this  paper  we  give  formal  descriptions  and  correctness  proofs  for  the  two  orphan 
management  algorithms  in  [9]  and  [16,  17].  The  algorithm  in  [9]  is  currently  in  use  in  the  Argus 
system.5  Our  proofs  are  completely  rigorous,  yet  quite  simple.  In  addition,  both  the 


5Our  analysis  covers  only  orphans  resulting  from  aborts  of  transactions  that  leave  running  descendants;  there  is 
another  component  of  the  Argus  algorithm  that  handles  orphans  that  result  f.  on;  node  crashes  in  which  the  contents 
of  volatile  memory  are  destroyed 
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presentations  and  the  proofs  follow  the  intuitions  that  the  designers  have  used  in  describing  the 
algorithms.  Although  the  two  algorithms  appear  to  be  quite  different,  our  proofs  show  that  the 
fundamental  concepts  underlying  them  are  very  similar;  in  fact,  each  can  be  regarded  as  an 
implementation  of  the  same  high-level  algorithm. 

Our  results  relate  the  behavior  of  a  system,  S’,  containing  an  orphan  management  algorithm  to 
that  of  a  corresponding  system,  S,  having  no  orphan  management;  namely,  S’  must  “simulate” 
S  in  the  sense  that  each  transaction  in  S’  must  see  a  view  of  the  system  that  it  could  see  in  an 
execution  of  S  in  which  it  is  not  an  orphan.  (A  transaction’s  “view”  of  the  system  is  its 
sequence  of  interactions  with  the  system,  including  the  results  of  operations  and  subtransactions 
invoked  by  the  transaction.)  When  system  S  includes  a  concurrency  control  algorithm  that 
ensures  that  non-orphans  see  consistent  views,  our  results  imply  that  in  S’,  all  transactions, 
orphan  as  well  as  non-orphan,  see  consistent  views.  This  result  provides  formal  justification  for 
an  informal  claim  sometimes  made  by  the  algorithms’  designers,  that  the  algoritnms  work  in 
combination  with  any  concurrency  control  algorithm. 

The  formal  model  used  in  this  paper  is  based  on  that  in  [11,  12,  4],  In  [11,  12],  Lynch  and 
Merritt  develop  a  model  for  nested  transaction  systems  including  aborts,  and  use  the  model  to 
show  that  an  exclusive  locking  variation  of  Moss’s  algorithm  [18]  ensures  correctness  for  non¬ 
orphans.  The  paper  [4]  contains  improvements  to  the  basic  model  in  [11.  12],  plus  proofs  that 
Moss’  read- write  algorithm  and  a  more  general  commutativity-based  locking  algorithm  also 
ensure  correctness  for  non-orphans.  In  this  paper  we  use  the  same  model  to  describe  the  two 
orphan  management  algorithms  mentioned  above,  to  state  correctness  properties,  and  to  prove 
the  algorithms  correct. 

1.2.  Related  Work 

Earlier  work  on  verifying  the  Argus  orphan  management  algorithm  appears  in  [6].  This  work 
is  based  on  an  earlier  model  for  nested  transaction  systems  that  is  described  in  [10].  The  results 
in  [6]  are  less  general  than  those  presented  here,  since  they  apply  only  to  the  specific 
concurrency  control  algorithm  (nested  locking)  used  by  Argus.  Moreover,  the  presentation  there 
is  much  more  complex  than  the  one  in  this  paper.  Much  of  the  complexity  in  [6]  arises  because 
the  treatments  of  concurrency  control  and  orphan  management  are  intermingled,  whereas  here 
we  are  able  to  separate  the  two.  The  model  in  [11,  12,  4]  provides  a  convenient  set  of  concepts 
for  describing  this  separation. 

Other  work  using  the  model  of  [1 1,  12,  4]  includes  [5,  2,  20];  these  papers  prove  correctness  of 
algorithms  for  replica  management,  timestamp-based  concurrency  control  and  distributed 
transaction  commit,  respectively.  The  fact  that  it  is  possible  to  use  the  model  to  explain  such  a 
variety  of  transaction-processing  algorithms  is  strong  evidence  that  it  is  a  very  useful  tool  for 
modeling  and  analyzing  nested  transaction  systems. 


1.3.  Organization  of  this  Paper 

The  remainder  of  the  paper  is  organized  as  follows.  Section  2  contains  some  preliminary 
mathematical  definitions  and  a  brief  description  of  HO  automata,  which  serve  as  the  formal 
foundation  for  our  work.  This  section  may  be  skipped  on  first  or  cursory  reading,  and  is 
included  in  order  to  make  the  technical  presentation  of  this  paper  entirely  self-contained.  Section 
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3  contains  a  definition  of  basic  systems,  a  general  class  of  transaction-processing  systems  to 
which  our  results  apply.  These  are  nested  transaction  systems  in  which  orphans  may  occur,  and 
for  which  the  problem  of  managing  orphans  can  be  precisely  and  intuitively  stated.  A  basic 
system  models  the  components  of  a  nested  transaction  system  as  I/O  automata.  Each  user 
program  is  modeled  as  a  transaction  automaton,  and  the  rest  of  the  system  (which  may  include  a 
division  into  objects,  and  may  include  concurrency  control  and  recovery  algorithms)  is  modeled 
as  a  single  basic  database  automaton.  A  basic  system  is  said  to  manage  orphans  correctly  if  it 
ensures  a  property  called  “serial  correctness’’  for  all  transactions,  orphans  and  non-orphans. 

Section  4  contains  some  definitions  and  results  about  the  dependencies  among  different  events 
in  a  basic  system;  these  concepts  underlie  the  results  in  the  rest  of  the  paper. 

Sections  5  through  8  contain  the  principal  contributions  of  this  paper,  in  which  we  piovc  he 
correctness  of  the  two  orphan  management  algorithms  in  [9]  and  [16,  17).  Our  proofs  have  an 
interesting  structure.  We  first  define  a  simple  abstract  algorithm  that  uses  global  information 
about  the  history  of  the  system,  and  show  that  it  ensures  that  orphans  see  consistent  views.  We 
then  formalize  the  Argus  algorithm  and  the  clocked  algorithm  from  [16]  in  a  way  that  only 
requires  the  use  ot  local  information,  and  show  that  each  simulates  the  more  abstract  algorithm. 
The  simulation  proofs  are  quite  simple,  and  do  not  require  re-proving  the  properties  already 
proved  for  the  abstract  algorithm.  The  correctness  of  the  Argus  and  clocked  algorithms  then 
follows  directly  from  the  correctness  of  the  abstract  algorithm. 

Each  orphan  management  algorithm  is  described  as  a  system  obtained  via  simple 
transformations  of  an  arbitrary  basic  system  without  orphan  management.  Each  of  these  systems 
contains  the  same  transactions  as  the  given  basic  system,  but  each  manages  orphans  using  a 
different  basic  database.  The  abstract  algorithm  is  modeled  by  the  filtered  database,  which 
maintains  information  about  the  global  history  of  the  system,  and  uses  tests  based  on  this  history 
information  to  prevent  orphans  from  learning  that  they  are  orphans.  The  Argus  database  models 
the  behavior  of  the  Argus  orphan  management  algorithm  (9);  it  manages  orphans  using  tests 
based  on  local  information  about  direct  dependencies  among  system  events.  The  strictly  filtered 
database  models  another  abstract  algorithm,  introduced  to  simplify  the  proof  of  the  correctness 
of  the  algorithm  in  [16];  it  also  uses  tests  based  on  global  history  information,  and  is  even  more 
restrictive  than  the  filtered  database.  Finally,  the  clock  database  models  the  orphan  management 
algorithm  from  [16];  it  manages  orphans  using  information  about  logical  clocks.  Each  of  these 
four  databases  is  described  as  the  result  of  a  transformation  of  the  basic  database. 

We  prove  that  the  filtered  system  (the  system  consisting  of  the  transactions  and  the  filtered 
database)  “simulates”  the  basic  system  in  the  sense  that  all  transactions,  including  orphans,  see 
a  “view”  that  they  could  see  in  the  basic  system,  in  an  execution  in  which  they  are  not  orphans. 
It  follows  that  if  the  basic  system  ensures  serial  correctness  for  non-orphan  transactions,  then  the 
filtered  system  ensures  serial  correctness  for  all  transactions.  We  also  prove  that  the  Argus 
system  “implements”  the  filtered  system,  and  so  inherits  the  same  correctness  property. 
Similarly,  we  prove  that  the  clock  system  implements  the  strictly  filtered  system,  which  in  turn 
implements  the  filtered  system,  thus  showing  that  the  clock  system  has  the  same  correctness 
property  as  the  filtered  system. 

Section  9  makes  some  of  the  preceding  general  concepts  more  concrete  by  describing  two 
particular  types  of  basic  systems,  taken  from  other  work  using  this  model.  The  first  kind  of  basic 
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system,  a  “generic  system,”  is  appropriate  for  describing  locking  algorithms,  while  the  second 
kind  of  basic  system,  a  “pseudotime  system,”  is  appropriate  for  describing  timestamp-based 
algorithms.  Both  kinds  of  systems  specialize  the  notion  of  a  basic  system  by  splitting  the  basic 
database  automaton  into  two  kinds  of  components:  an  “object  automaton”  for  each  object  in  the 
system  and  a  “controller  automaton”  that  links  the  transactions  and  objects  together.  The 
concurrency  control  and  recovery  performed  by  the  system  is  encapsulated  within  the  object 
automata.  The  two  kinds  of  systems  differ  in  that  they  have  slightly  different  interfaces  between 
the  objects  and  the  controller.  Particular  information  flow  dependencies  are  described  for  both 
of  these  kinds  of  basic  systems. 

Section  10  contains  a  summary  of  our  results  and  some  suggestions  for  further  work. 

2.  Formal  Preliminaries 

An  irreflexive  partial  order  is  a  binary  relation  that  is  irreflexive,  antisymmetric  and  transitive. 

The  formal  subject  matter  of  this  paper  is  concerned  with  finite  and  infinite  sequences 
describing  the  executions  of  automata.  Usually,  we  will  be  discussing  sequences  of  elements 
from  a  universal  set  of  actions.  Formally,  a  sequence  (3  of  actions  is  a  mapping  from  a  prefix  of 
the  positive  integers  to  the  set  of  actions.  We  describe  the  sequence  by  listing  the  images  of 
successive  integers  under  the  mapping,  writing  {3  =  Ttj^Ttj....6  Since  the  same  action  may  occur 
several  times  in  a  sequence,  it  is  convenient  to  distinguish  the  different  occurrences.  Thus,  we 
refer  to  a  particular  occurrence  of  an  action  in  a  sequence  as  an  event.  Formally,  an  event  in  a 
sequence  [3  =  of  actions  is  an  ordered  pair  (i,7t),  where  i  is  a  positive  integer  and  ji  is  an 

action,  such  that  7tj,  the  i111  action  in  (3,  is  tz. 

A.  set  of  sequences  P  is  prefix-closed  provided  that  whenever  (3  e  P  and  y  is  a  prefix  of  (3,  it  is 
also  the  case  that  ys  P.  Similarly,  a  set  of  sequences  P  is  limit-closed  provided  that  any 
sequence  all  of  whose  finite  prefixes  are  in  P  is  also  in  P.  We  refer  to  any  nonempty,  prefix- 
closed  and  limit-closed  set  of  sequences  as  a  safety  property. 

2.1.  The  Input/Output  Automaton  Model 

In  order  to  reason  carefully  about  complex  concurrent  systems  such  as  those  that  implement 
atomic  transactions,  it  is  important  to  have  a  simple  and  clearly  defined  formal  model  for 
concurrent  computation.  The  model  we  use  for  our  work  is  the  input! output  automaton 
model  [14,  15].  This  model  allows  careful  and  readable  descriptions  of  concurrent  algorithms 
and  of  the  correctness  conditions  that  they  are  supposed  to  satisfy.  The  model  can  serve  as  the 
basis  for  rigorous  proofs  that  particular  algorithms  satisfy  particular  correctness  conditions. 

This  subsection  contains  an  introduction  to  a  simple  special  case  of  the  model  that  is  sufficient 
for  use  in  this  paper.  In  particular,  in  this  paper  we  consider  properties  of  finite  executions  only, 
and  do  not  consider  “liveness”  or  “fairness”  properties. 

Each  system  component  is  modeled  as  an  “I/O  automaton,”  which  is  a  mathematical  object 


6We  use  the  symbols  P,  y,...  for  sequences  of  actions  and  the  symbols  n.  <j>  and  for  individual  actions. 
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somewhat  like  a  traditional  finite-state  automaton.  However,  an  I/O  automaton  need  not  be 
finite-state,  but  can  have  an  infinite  state  set.  The  actions  of  an  I/O  automaton  are  classified  as 
either  “input,”  “output”  or  “internal.”  This  classification  is  a  reflection  of  a  distinction 
between  events  (such  as  the  receipt  of  a  message)  that  are  caused  by  the  environment,  events 
(such  as  sending  a  message)  that  the  component  can  perform  when  it  chooses  and  that  affect  the 
environment,  and  events  (such  as  changing  the  value  of  a  local  variable)  that  a  component  can 
perform  when  it  chooses,  but  that  are  undetectable  by  the  environment  except  through  their 
effects  on  later  events.  In  the  model,  an  automaton  generates  output  and  internal  actions 
autonomously,  and  transmits  output  actions  instantaneously  to  its  environment.  In  contrast,  the 
automaton’s  input  is  generated  by  the  environment  and  transmitted  instantaneously  to  the 
automaton.  The  distinction  between  input  and  other  actions  is  fundamental,  based  on  who 
determines  when  the  action  is  performed:  an  automaton  can  establish  restrictions  on  when  it  will 
perform  an  output  or  internal  action,  but  it  is  unable  to  block  the  performance  of  an  input  action. 

2.1.1.  Action  Signatures 

The  formal  description  of  an  automaton’s  actions  and  their  classification  into  inputs,  outputs 
and  internal  actions  is  given  by  its  “action  signature.”  An  action  signature  S  is  an  ordered  triple 
consisting  of  three  pairwise-disjoint  sets  of  actions.  We  write  in( S),  out( S)  and  int{ S)  for  the 
three  components  of  S,  and  refer  to  the  actions  in  the  three  sets  as  the  input  actions,  output 
actions  and  internal  actions  of  S,  respectively.  We  let  ext(S)  =  in(S)  u  out(S)  and  refer  to  the 
actions  in  ext(S)  as  the  external  actions  of  S.  Also,  we  let  local( S)  =  int(S)  u  out(S),  and  refer  to 
the  actions  in  local(S)  as  the  locally  controlled  actions  of  S.  Finally,  we  let  acw(S)  =  in(S)  u 
out(S)  u  int(S),  and  refer  to  the  actions  in  acts(S)  as  the  actions  of  S. 

An  external  action  signature  is  an  action  signature  consisting  entirely  of  external  actions,  that 
is,  having  no  internal  actions.  If  S  is  an  action  signature,  then  the  external  action  signature  of  S 
is  the  action  signature  extsigi S)  =  (in(S),out(S),0),  i.e.,  the  action  signature  that  is  obtained  from 
S  by  removing  the  internal  actions. 

2.1.2.  Input/Output  Automata 

An  inputloutput  automaton  A  (also  called  an  HO  automaton  or  simply  an  automaton)  consists 
of  four  components:7 

•  an  action  signature  sig( A), 

•  a  set  states{ A)  of  states, 

•  a  nonempty  set  start(A)  c  states(A)  of  start  states,  and 

•  a  transition  relation  steps(A)  £  states(A)  x  acts(sig(A))  x  states(A),  with  the 
property  that  for  every  state  s’  and  input  action  n  there  is  a  transition  (s’,7t,s)  in 
steps(A). 

Note  that  the  set  of  states  need  not  be  finite.  We  refer  to  an  element  (s’,rc,s)  of  steps(A)  as  a 
step  of  A.  The  step  (s’,7t,s)  is  called  an  input  step  of  A  if  7t  is  an  input  action,  and  output  steps, 
internal  steps,  external  steps  and  locally  controlled  steps  are  defined  analogously.  If  (s’,7t,s)  is  a 


7I/0  automata,  as  defined  in  [14],  also  include  a  fifth  component,  which  is  used  for  describing  fair  executions. 
We  omit  it  here  as  it  is  not  needed  for  the  results  described  in  this  paper. 
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step  of  A,  then  k  is  said  to  be  enabled  :n  s’.  Since  every  input  action  is  enabled  in  every  state, 
automata  are  said  to  be  input-enabled.  The  input-enabling  property  means  that  an  automaton  is 
not  able  to  block  input  actions.  If  A  is  an  automaton,  we  sometimes  write  acts(A)  as  shorthand 
for  acts(sig(A)),  and  likewise  for  in(A),  out(A),  etc.  An  I/O  automaton  A  is  said  to  be  closed  if 
all  its  actions  are  locally  controlled,  i.e.,  if  in(A)  =  0. 

Note  that  an  I/O  automaton  can  be  “nondeterministic,”  by  which  we  mean  two  things:  that 
more  than  one  locally  controlled  action  can  be  enabled  in  the  same  state,  and  that  the  same 
action,  applied  in  the  same  state,  can  lead  to  different  successor  states.  This  nondeteiminism  is 
an  important  part  of  the  model’s  descriptive  power.  Describing  algorithms  as 
nondeterministically  as  possible  tends  to  make  results  about  the  algorithms  quite  general,  since 
many  results  about  nondeterministic  algorithms  apply  a  fortiori  to  all  algorithms  obtained  by 
restricting  the  nondeterminisdc  choices.  Moreover,  the  use  of  nondeterminism  helps  to  avoid 
cluttering  algorithm  descriptions  and  proofs  with  inessential  details.  Finally,  the  uncertainties 
introduced  by  asynchrony  make  nondeterminism  an  intrinsic  property  of  real  concurrent  systems, 
and  so  an  important  property  to  capture  in  our  formal  model  of  such  systems. 

2.1.3.  Executions,  Schedules  and  Behaviors 

When  a  system  is  modeled  by  an  I/O  automaton,  each  possible  run  of  the  system  is  modeled  by 
an  “execution,”  an  alternating  sequence  of  states  and  actions.  The  possible  activity  of  the 
system  is  captured  by  the  set  of  all  possible  executions  that  can  be  generated  by  the  automaton. 
However,  not  all  the  information  contained  in  an  execution  is  important  to  a  user  of  the  system, 
nor  to  an  environment  in  which  the  system  is  placed.  We  believe  that  what  is  important  about 
the  activity  of  a  system  is  the  externally  visible  events,  and  not  the  states  or  internal  events. 
Thus,  we  Iticus  on  the  uuiomaton’o  “behaviors”  —  the  subsequences  of  its  executions 
consisting  of  external  (i.e.,  input  and  output)  actions.  We  regard  a  system  as  suitable  for  a 
purpose  if  any  possible  sequence  of  externally  visible  events  has  appropriate  characteristics. 
Thus,  in  the  model,  we  formulate  correctness  conditions  for  an  I/O  automaton  in  terms  of 
properties  of  the  automaton’s  behaviors. 

Formally,  an  execution  fragment  of  A  is  a  finite  sequence  SqTCjS^.. -7tnsn  or  infinite  sequence 
s07Tisi7C2  -Knsn”-  alternating  states  and  actions  of  A  such  that  (Si,rc;+i,si+1)  is  a  step  of  A  for 
every  i  for  which  i+1  exists.  An  execution  fragment  beginning  with  a  start  state  is  called  an 
execution.  We  denote  the  set  of  executions  of  A  by  execs( A),  and  the  set  of  finite  executions  of 
A  by  finexecsi A).  A  state  is  said  to  be  reachable  in  A  if  it  is  the  final  state  of  a  finite  execution 
of  A. 

The  schedule  of  an  execution  fragment  a  of  A  is  the  subsequence  of  a  consisting  of  actions, 
and  is  denoted  by  sched(a).  We  say  that  (3  is  a  schedule  of  A  if  P  is  the  schedule  of  an  execution 
of  A.  We  denote  the  set  of  schedules  of  A  by  scheds(A)  and  the  set  of  finite  schedules  of  A  by 
finscheds(A).  The  behavior  of  a  sequence  P  of  actions  in  acts(A),  denoted  by  beh{ P),  is  the 
subsequence  of  p  consisting  of  actions  in  ext(A).  The  behavior  of  an  execution  fragment  a  of  A, 
denoted  by  beh( a),  is  defined  to  be  beh(sched(a)).  We  say  that  p  is  a  behavior  of  A  if  P  is  the 
behavior  of  an  execution  of  A.  We  denote  the  set  of  behaviors  of  A  by  behs(A)  and  the  set  of 
finite  behaviors  of  A  by  finbehs(A). 

We  say  that  a  finite  schedule  p  of  A  can  leave  A  in  state  s  if  there  is  some  finite  execution  a  of 
A  with  final  state  s  and  with  sched(a)  =  p.  Similarly,  a  finite  behavior  p  of  A  can  leave  A  in 
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state  s  if  there  is  some  finite  execution  a  of  A  with  final  state  s  and  with  beh(a)  =  (3.  We  say  that 
an  action  n  is  enabled  after  a  finite  schedule  or  behavior  [3  of  A  if  there  is  a  state  s  such  that  [3 
can  leave  A  in  state  s  and  n  is  enabled  in  s. 

An  extended  step  of  an  automaton  A  is  a  triple  of  the  form  (s\j3,s),  where  s’  and  s  are  in 
states(A),  (3  is  a  finite  sequence  of  actions  in  acts(A),  and  there  is  an  execution  fragment  of  A 
having  s’  as  its  first  state,  s  as  its  last  state  and  3  as  its  schedule. 

If  p  is  any  sequence  of  actions  and  d>  is  a  set  of  actions,  we  write  3'^  to  denote  the 
subsequence  of  3  containing  all  occurrences  of  actions  in  O.  If  A  is  an  automaton,  we  write  3!A 
for  Blacts(A). 

2.2.  Composition 

Often,  a  single  system  can  also  be  viewed  as  a  combination  of  several  component  systems 
interacting  with  one  another.  To  reflect  this  in  our  model,  we  define  a  “composition”  operation 
by  which  several  I/O  automata  can  be  combined  to  yield  a  single  I/O  automaton.  Our 
composition  operator  connects  each  output  action  of  the  component  automata  with  the 
identically  named  input  actions  of  any  number  (usually  one)  of  the  other  component  automata. 
In  the  resulting  system,  an  output  action  is  generated  autonomously  by  one  component  and  is 
thought  of  as  being  instantaneously  transmitted  to  all  components  having  the  same  action  as  an 
input.  All  such  components  are  passive  recipients  of  the  input,  and  take  steps  simultaneously 
with  the  output  step. 

2.2.1.  Composition  of  Action  Signatures 

We  first  define  composition  of  action  signatures.  Let  I  be  an  index  set  that  is  at  most 
countable.  A  collection  {Sj}i€l  of  action  signatures  is  said  to  be  strongly  compatible 8  if  the 
following  properties  hold: 

1.  out(Sj)  n  out(Sj)  =  0  for  all  i,  j  €  I  such  that  i*j, 

2.  int(Sj)  n  acts(Sj)  =  0  for  all  i,  j  e  I  such  that  i*j,  and 

3.  no  action  is  in  acts(Sj)  for  infinitely  many  i. 

Thus,  no  action  is  an  output  of  more  than  one  signature  in  the  collection,  and  internal  actions  of 
any  signature  do  not  appear  in  any  other  signature  in  the  collection.  Moreover,  we  do  not  permit 
actions  involving  infinitely  many  component  signatures. 

The  composition  S  =  TTie  jSj  of  a  collection  of  strongly  compatible  action  signatures  { ie  t  is 
defined  to  be  the  action  signature  with 

•  in(S)  =  u^in^)  -  uieIout(Si), 

•  out(S)  =  u^outCSj),  and 

•  int(S)  =  uie  jintlSj). 

Thus,  output  actions  are  those  that  are  outputs  of  any  of  the  component  signatures,  and  similarly 


*A  weaker  notion  called  “compatibility”  is  defined  in  [14],  consisting  of  the  first  two  of  the  three  given 
properties  only.  For  the  purposes  of  this  paper,  only  the  stronger  notion  will  be  required. 


8 


for  internal  actions.  Input  actions  are  any  actions  that  are  inputs  to  any  of  the  component 
signatures,  but  outputs  of  no  component  signature. 

2.2.2.  Composition  of  Automata 

A  collection  {Aj}iGl  of  automata  is  said  to  be  strongly  compatible  if  their  action  signatures  are 
strongly  compatible.  The  composition  A  =  nigIAj  of  a  strongly  compatible  collection  of 
automata  { At } ie  j  has  the  following  components:5 

•  sig(A)  =  nieIsig(A,), 

•  states(A)  =  ni€l  states(A,), 

•  start(A)  =  ni6l  startiAi),  and 

•  steps(A)  is  the  set  of  triples  (s’,rc,s)  such  that  for  all  i  e  I,  (a)  if  7i  e  acts(A|)  then 
(s’[i],7t,s[i])  €  stepsCAj),  and  (b)  if  7t  «  acts(Aj)  then  s’[i]  =  s[i].10 

Since  the  automata  Aj  are  input-enabled,  so  is  their  composition,  and  hence  their  composition 
is  an  automaton.  Each  step  of  the  composition  automaton  involves  all  the  automata  that  have  a 
particular  action  in  their  action  signature  performing  that  action  concurrently,  while  the  automata 
that  do  not  have  that  action  in  their  signature  do  nothing.  We  will  often  refer  to  an  automaton 
formed  by  composition  as  a  “system”  of  automata. 

If  a  =  Sq7C1S|...  is  an  execution  of  A,  let  alAj  be  the  sequence  obtained  by  deleting  itjSj  when  7Cj 
is  not  an  action  of  Aj,  and  replacing  the  remaining  s.  by  Sj[i].  Recall  that  we  have  previously 
defined  a  projection  operator  for  action  sequences.  The  two  projection  operators  are  related  in 
the  obvious  way:  sched(alAi)  =  schedCajlA^,  and  similarly  beh(aiAj)  =  behfajlAj. 

In  the  course  of  our  discussions  we  will  often  reason  about  automata  without  specifying  their 
internal  actions.  To  avoid  tedious  arguments  about  compatibility,  henceforth  we  assume  that 
unspecified  internal  actions  of  any  automaton  are  unique  to  that  automaton,  and  do  not  occur  as 
internal  or  external  actions  of  any  of  the  other  automata  we  discuss. 

All  of  the  systems  that  we  will  use  for  modeling  transactions  are  closed  systems,  that  is,  each 
action  is  an  output  of  some  component.  Also,  each  output  of  a  component  will  be  an  input  of  at 
most  one  other  component. 

2.2.3.  Properties  of  Systems  of  Automata 

Here  we  give  basic  results  relating  executions,  schedules  and  behaviors  of  a  system  of 
automata  to  those  of  the  automata  being  composed.  The  first  result  says  that  the  projections  of 
executions  of  a  system  onto  the  components  are  executions  of  the  components,  and  similarly  for 
schedules,  etc. 

Proposition  1:  Let  { Ai } ie  t  be  a  strongly  compatible  collection  of  automata,  and  let 


^oie  that  the  second  and  third  components  listed  are  just  ordinary  Cartesian  products,  while  the  first  component 
uses  the  previous  definition  of  composition  of  action  signatures. 

10 We  use  the  notation  s[i]  to  denote  the  Ith  component  of  the  state  vector  s. 
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A  =  nigIAj.  If  a  e  execs(A)  then  alAj  e  execs(Aj)  for  all  i  e  I.  Moreover,  the  same 
result  holds  for  finexecs,  scheds,  finscheds,  behs  and  finbehs  in  place  of  execs. 

Converses  can  also  be  proved  for  all  the  parts  of  the  preceding  proposition.  The  following  are 
most  useful.  They  say  that  schedules  and  behaviors  of  component  automata  can  be  “patched 
together”  to  form  schedules  and  behaviors  of  the  composition. 

Proposition  2:  Let  (Aj}i€l  be  a  strongly  compatible  collection  of  automata,  and  let 
A  =  ni€  jAj. 

1.  Let  p  be  a  sequence  of  actions  in  acts(A).  If  piAj  e  scheds(Aj)  for  all  i  6  I, 
then  (3  e  scheds(A). 

2.  Let  P  be  a  finite  sequence  of  actions  in  acts(A).  If  pi Ai  e  finscheds(A;)  for  all 
i  e  I,  then  P  e  finscheds(A). 

3.  Let  P  be  a  sequence  of  actions  in  ext(A).  If  piAj  €  behs(A;)  for  all  i  e  I,  then 
P  e  behs(A). 

4.  Let  P  be  a  finite  sequence  of  actions  in  ext(A).  If  plAi  e  finbehs(A,)  for  all  i 
e  I,  then  P  e  finbehs(A). 

The  preceding  proposition  is  useful  in  proving  that  a  sequence  of  actions  is  a  behavior  of  a 
system  A:  it  suffices  to  show  that  the  sequence’s  projections  are  behaviors  of  the  components  of 
A  and  then  to  appeal  to  Proposition  2. 

2.3.  Implementation 

We  define  a  notion  of  “implementation”  of  one  automaton  by  another.  Let  A  and  B  be 
automata  with  the  same  external  action  signature,  i.e.,  with  extsig(A)  =  extsig(B).  Then  A  is  said 
to  implement  B  if  finbehs(A)  c  finbehs(B).  One  way  in  which  this  notion  can  be  used  is  the 
following.  Suppose  we  can  show  that  an  automaton  B  is  “correct,”  in  the  sense  that  its  finite 
behaviors  all  satisfy  some  specified  property.  Then  if  another  automaton  A  implements  B,  A  is 
also  correct.  One  can  also  show  that  if  A  implements  B,  then  replacing  B  by  A  in  any  system 
yields  a  new  system  in  which  all  finite  behaviors  are  behaviors  of  the  original  system. 

One  useful  technique  for  showing  that  one  automaton  implements  another  is  to  give  a 
correspondence  between  states  of  the  two  automata.  Such  a  correspondence  can  often  be 
expressed  in  the  form  of  a  kind  of  abstraction  mapping  that  we  call  a  “possibilities  mapping,” 
defined  as  follows.  Suppose  A  and  B  are  automata  with  the  same  external  action  signature,  and 
suppose  f  is  a  mapping  from  states(A)  to  the  power  set  of  states(B).  That  is,  if  s  is  a  state  of  A, 
f(s)  is  a  set  of  states  of  B.  The  mapping  f  is  said  to  be  a  possibilities  mapping  from  A  to  B  if  the 
following  conditions  hold: 

1.  For  every  start  state  s0  of  A,  there  is  a  start  state  t0  of  B  such  that  tQ  e  f(s0). 

2.  Let  s’  be  a  reachable  state  of  A,  t’  €  f(s’)  a  reachable  state  of  B,  and  (s’,7t,s)  a  step 
of  A.  Then  there  is  an  extended  step  (t’,y,t)  of  B  (possibly  having  an  empty 
schedule)  such  that  the  following  conditions  are  satisfied: 

a.  ylext(B)  =  rclext(A),  and 

b.  t  e  f(s). 
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The  following  proposition  shows  that  giving  a  possibilities  mapping  from  A  to  B  is  sufficient 
to  show  that  A  implements  B. 

Proposition  3:  Suppose  that  A  and  B  are  automata  with  the  same  external  action 
signature  and  there  is  a  possibilities  mapping,  f,  from  A  to  B.  Then  A  implements  B. 


2.4.  Preserving  Properties 

Although  automata  in  our  model  are  unable  to  block  input  actions,  it  is  often  convenient  to 
restrict  attention  to  those  behaviors  in  which  the  environment  provides  inputs  in  a  “sensible” 
way,  that  is,  where  the  environment  obeys  certain  “well-formedness”  restrictions.  A  useful  way 
of  discussing  such  restrictions  is  in  terms  of  the  notion  that  an  automaton  “preserves”  a  property 
of  behaviors:  as  long  as  the  environment  does  not  violate  the  property,  neither  does  the 
automaton.  Such  a  notion  is  primarily  interesting  for  safety  properties.  Let  d>  be  a  set  of  actions 
and  P  a  safety  property  for  sequences  of  actions  in  <3>.  Let  A  be  an  automaton  with  O  n  int(A)  = 
0.  We  say  that  A  preserves  P  if  (3rcO  e  P  whenever  (30  e  P,  it  e  out(A)  and  prclA  € 
finbehs(A). 

Thus,  if  an  automaton  preserves  a  property  P,  the  automaton  is  not  the  first  to  violate  P:  as 
long  as  the  environment  only  provides  inputs  such  that  the  cumulative  behavior  satisfies  P,  the 
automaton  will  only  perform  outputs  such  that  the  cumulative  behavior  satisfies  P.  In  many 
cases  of  interest,  we  will  have  O  c  ext(A);  note  that  even  in  this  case,  the  fact  that  an  automaton 
A  preserves  P  does  not  imply  that  all  of  A’s  behaviors,  when  restricted  to  O,  satisfy  P.  It  is 
possible  for  a  behavior  of  A  to  fail  to  satisfy  P,  if  an  input  causes  a  violation  of  P.  However,  the 
following  proposition  gives  a  way  to  deduce  that  all  of  a  system’s  behaviors  satisfy  P.  The 
proposition  says  that,  under  certain  conditions,  if  all  components  cf  a  system  preserve  P,  then  all 
the  behaviors  of  the  composition  satisfy  P. 

Proposition  4:  Let  (AjJ^j  be  a  strongly  compatible  collection  of  automata  and  let  A 
=  nieIAj.  Let  O  be  a  set  of  actions  such  that  O  n  int(A)  =  0,  and  let  P  be  a  safety 
property  for  actions  in  O.  Suppose  that  for  each  i  €  I,  At  preserves  P.  Then  A 

preserves  P.  Furthermore,  if  O  n  in(A)  =  0,  then  behs(A)0  c  P.  That  is,  if  (3  e 
behs(A),  then  (310  €  P. 

Proof:  Let  (3  be  a  sequence  of  actions  such  that  (30  e  P,  n  e  out(A)  and  (3rcf A  € 
finbehs(A).  Then  it  €  out(Aj)  fi,r  some  i  €  I,  and  (3jtlAj  e  finbehsIAj),  by  Proposition 
2.  Since  Aj  preserves  P,  (3itO  €  P. 

Now  suppose  that  <!>  n  in(A)  =  0,  and  let  (3  e  behs(A).  Since  A  preserves  P,  by  a 
simple  induction,  every  finite  prefix  of  (30  is  in  P.  Then  (30  6  P,  by  the  limit-closure 
ofP.  □ 

3.  Basic  Systems 

In  this  section,  we  define  “basic  systems,”  the  class  of  transaction-processing  systems  to 
which  our  results  apply.  Basic  systems  generalize  both  the  generic  systems  of  [4]  and  the 
pseudotime  systems  of  [2].  We  also  define  correctness  conditions  for  basic  systems,  in 
particular,  the  notion  of  correc-  management  of  orphans. 
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3.1.  Overview 

Transaction-processing  systems  consist  of  user-provided  nansaction  code,  plus  transaction- 
processing  algorithms  designed  to  coordinate  the  activities  of  different  transactions.  The 
transactions  are  written  by  application  programmers  in  a  suitable  programming  language. 
Transactions  are  permitted  to  invoke  operations  on  data  objects.  In  addition,  if  nesting  is 
allowed,  transactions  can  invoke  subtransactions  and  receive  responses  from  the  subtransactions 
describing  the  results  of  their  processing. 

In  a  transaction-processing  system,  the  transaction-processing  algorithms  interact  with  the 
transactions,  making  decisions  about  when  to  schedule  subtransactions  and  operations  on  data 
objects.  The  transaction-processing  algorithms  include  concurrency  control  and  recovery 
algorithms.  In  many  interesting  cases  (e.g.,  for  locking  algorithms),  the  transaction-processing 
algorithms  can  be  naturally  divided  into  a  “controller”  and  a  collection  of  “objects,”  where 
each  object  includes  concurrency  control  and  recovery  algorithms  appropriate  for  that  object  and 
the  controller  manages  communication  among  the  transactions  and  objects.  We  do  not,  however, 
require  this  division  for  our  general  results. 

The  transaction-processing  systems  studied  in  this  paper  are  called  “basic  systems.”  In  the 
organization  we  consider,  the  transaction-processing  algorithms  are  represented  by  a  component 
called  a  “basic  database.”  Each  component  of  a  basic  system  is  modeled  as  an  I/O  automaton. 
That  is,  each  transaction  is  an  automaton,  and  the  basic  database  is  another  automaton. 

The  nested  structure  of  transactions  is  modeled  by  describing  each  transaction  and 
subtransaction  in  the  transaction  nesting  structure  as  a  separate  I/O  automaton.  If  a  parent 
transaction  T  wishes  to  invoke  a  child  transaction  T\  T  issues  an  output  action  that  “requests 
that  T’  be  created.”  The  basic  database  receives  this  request,  and  at  some  later  time  mig ct  issue 
an  action  that  is  an  input  to  the  child  T’  and  corresponds  to  the  “creation”  of  T\  T1  s,  the 
different  transactions  in  the  nesting  structure  comprise  a  forest  of  automata,  communicatin  i  with 
each  other  indirectly  through  the  basic  database.  The  highest-level  transactions,  i.e.,  thos'  that 
are  not  subtransactions  of  any  other  transactions,  are  the  roots  in  this  forest. 

It  is  actually  more  convenient  to  model  the  transaction  nesting  structure  as  a  tree  rather  than  as 
a  forest.  Therefore,  we  add  an  extra  “root”  automaton  as  a  “dummy  transaction,”  located  at 
the  top  of  the  transaction  nesting  structure.  The  highest-level  user-defined  transactions  are 
considered  to  be  children  of  this  new  root.  The  root  can  be  thought  of  as  modeling  the  outside 
world,  from  which  invocations  of  top-level  transactions  originate  and  to  which  repons  about  the 
results  of  such  transactions  are  sent. 

In  the  rest  of  this  section,  we  define  “basic  systems”  and  state  the  correctness  conditions  that 
they  are  supposed  to  satisfy. 


3.2.  System  Types 

We  begin  by  defining  a  type  structure  that  will  be  used  to  name  the  transactions  and  objects  in 
a  basic  system. 

A  system  type  consists  of  the  following: 

•  a  set  To f  transaction  names. 


•  a  distinguished  transaction  name  T0  e  T, 

•  a  subset  accesses  of  /’not  containing  Tq, 

•  a  mapping  parent.  T-  {Tq}  T,  which  configures  the  set  of  transaction  names  into 
a  tree,  with  T0  as  the  root  and  the  accesses  as  the  leaves, 

•  a  set  X of  object  names, 

•  a  mapping  object:  accesses  — >  X,  and 

•  a  set  V  of  return  values. 

Each  element  of  the  set  “accesses”  is  called  an  access  transaction  name,  or  simply  an  access. 
Also,  if  object(T)  =  X  we  say  that  T  is  an  access  to  X. 

In  referring  to  the  transaction  tree,  we  use  standard  tree  terminology,  such  as  “leaf  node,” 
“internal  node,”  “child,”  “ancestor,”  and  “descendant.”  As  a  special  case,  we  consider  any 
node  to  be  its  own  ancestor  and  its  own  descendant,  i.e.,  the  “ancestor”  and  “descendant” 
relations  are  reflexive.  We  also  use  the  notion  of  a  “least  common  ancestor”  of  two  nodes. 

The  transaction  tree  describes  the  nesting  structure  for  transaction  names,  with  Tq  as  the  name 
of  the  dummy  “root  transaction.”  Each  child  node  in  this  tree  represents  the  name  of  a 
subtransaction  of  the  transaction  named  by  its  parent.  The  children  of  Tq  represent  names  of  the 
top-level  user-defined  transactions.  The  accesses  represent  names  for  the  lowest-level 
transactions  in  the  transaction  nesting  structure;  we  will  use  these  lowest-level  transaction  names 
to  model  operations  on  data  objects.  Thus,  the  only  transactions  that  actually  access  data  are  the 
leaves  of  the  transaction  tree  and  these  do  nothing  else.  The  internal  nodes  model  transactions 
whose  function  is  to  create  and  manage  subtransactions  including  accesses,  but  they  do  not 
access  data  directly. 

The  tree  structure  should  be  thought  of  as  a  predefined  naming  scheme  for  all  possible 
transactions  that  might  ever  be  invoked.  In  any  particular  execution,  however,  only  some  of 
these  transactions  will  actually  take  steps.  We  imagine  that  the  tree  structure  is  known  in 
advance  by  all  components  of  a  system.  The  tree  will,  in  general,  be  an  infinite  structure  with 
infinite  branching. 

The  set  TTs  the  set  of  names  for  the  objects  used  in  the  system.  Each  access  transaction  name 
is  assumed  to  be  an  access  to  some  particular  object,  as  designated  by  the  “object”  mapping. 
The  set  V  of  return  values  is  the  set  of  possible  values  that  might  be  returned  by  successfully 
completed  transactions  to  their  parent  transactions. 

For  the  rest  of  this  paper,  we  will  fix  a  particular  system  type. 

3.3.  General  Structure  of  Basic  Systems 

A  basic  system  for  a  given  system  type  is  a  closed  system  consisting  of  a  “transaction 
automaton”  AT  for  each  non-access  transaction  name  T  and  a  single  “basic  database 
automaton”  B.  Later  in  this  section,  we  will  give  conditions  to  be  satisfied  by  the  transaction 
and  basic  database  automata.  Here,  we  just  describe  the  signatures  of  these  automata,  in  order  to 
explain  how  the  automata  are  interconnected. 
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Figure  1  depicts  the  structure  of  a  basic  system. 


Figure  1:  Basic  System 


The  transaction  nesting  structure  is  indicated  in  part  by  dotted  lines  between  transaction 
automata  corresponding  to  parent  and  child.  Access  transactions  do  not  have  associated 
automata,  and  so  the  diagram  does  not  indicate  the  parents  of  accesses.  The  direct  connections 
between  automata  (via  shared  actions)  are  indicated  by  solid  lines.  Thus,  the  transaction 
automata  interact  directly  with  the  basic  database,  but  not  directly  with  each  other. 


Figure  2:  Transaction  Interface 


Figure  2  shows  the  interface  of  a  transaction  automaton  in  more  detail.  The  automaton  for 
transaction  name  T  has  an  input  action  CREATE(T),  which  is  generated  by  the  basic  database  in 
order  to  initiate  T’s  processing.  We  do  not  include  explicit  arguments  to  a  transaction  in  our 
model;  rather  we  suppose  that  there  is  a  different  transaction  for  each  possible  set  of  arguments, 
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and  so  any  input  to  the  transaction  is  encoded  in  the  name  of  the  transaction.  T  has 
REQUEST_CREATE(T)  actions  for  each  child  T*  of  T  in  the  transaction  nesting  structure; 
these  are  requests  for  creation  of  child  transactions,  and  are  communicated  directly  to  the  basic 
database.  At  some  later  time,  the  basic  database  might  respond  to  a  REQUEST.CREATE(T’) 
action  by  issuing  a  CREATE(T’)  action;  in  case  T  is  not  an  access,  this  action  is  an  input  to  the 
automaton  for  transaction  T\  T  also  has  R£PORT_COMMIT(T,v)  and  REPORT. ABORT(T) 
input  actions,  by  which  the  basic  database  informs  T  about  the  fate  (commit  or  abort)  of  its 
previously  requested  child  T\  In  the  case  of  a  commit,  the  report  includes  a  return  value  v  that 
provides  information  about  the  activity  of  T’;  in  the  case  of  an  abort,  no  information  is  returned. 
Finally,  T  has  a  REQUEST_COMMIT(T,v)  output  action,  by  which  it  announces  to  the  basic 
database  that  it  has  completed  its  activity  successfully,  with  a  particuLu  ret  alt  that  is  described 
by  return  value  v. 

CREATE 

REQUEST.COMMIT  (accesses) 


COMMIT 

ABORT 

REPORT.COMMIT 

REPORT.ABORT 


RFQUEST.CREATE 

REQUEST.COMMIT 


Basic 

Database 


Figure  3:  Basic  Database  Interface 


Figure  3  shows  the  basic  database  interface.  The  basic  database  in  any  particular  baste  system 
receives  the  previously  mentioned  REQUEST.CREATE  and  REQUEST.COMMIT  actions  as 
inputs  from  the  transaction  automata.  It  produces  CREATE  actions  as  outputs,  thereby 
awakening  transaction  automata  or  invoking  operations  on  objects.  The  basic  database  also 
produces  REQUEST_COMMIT(T,v)  output  actions  for  accesses  T;  these  represent  responses  to 
the  invocations  of  operations  on  objects.  The  value  v  in  a  REQUEST_COMMIT(T,v)  action  is  a 
return  value  returned  by  the  operation  as  pan  of  its  response.  The  basic  database  also  produces 
COMMIT(T)  and  ABORT(T)  actions  for  arbitrary  tran 'action  names  T  *  T0,  representing 
decisions  about  whether  the  designated  transaction  commits  or  aborts.  For  technical 
convenience,  we  classify  the  COMMIT  and  ABORT  actions  and  the  REQUEST.COMMIT  and 
CREATE  actions  for  access  transactions  as  output  actions  of  the  basic  database,  even  when  they 
are  not  inputs  to  any  other  system  component.11  The  basic  database  also  has 
REPORT.COMMIT  and  REPORT.ABORT  actions  as  outputs,  by  which  it  communicates  the 
fates  of  transactions  to  their  parents. 

Different  basic  databases  may  include  additional  output  actions.  The  final  section  of  this  paper 


"Classifying  actions  as  outputs  even  though  they  are  not  inputs  to  any  other  system  component  is  permissible  in 
the  I/O  automaton  model.  In  this  case,  it  would  also  be  possible  to  classify  these  actions  as  internal  actions  of  the 
basic  database,  but  then  the  statements  and  proofs  of  the  ensuing  results  would  be  more  complicated. 
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describes  “generic  databases,”  which  have  additional  outputs  by  which  the  fates  of  transactions 
are  communicated  to  the  objects,  so  that  locks  may  be  released.  “Pseudotime  databases”  are  a 
second  example,  which  contain  additional  outputs  involving  the  management  of  timestamp  data. 

As  is  always  the  case  for  I/O  automata,  the  components  of  a  system  are  determined  statically. 
Even  though  we  referred  earlier  to  the  action  of  “creating”  a  child  transaction,  the  model  treats 
the  child  transaction  as  if  it  had  been  there  all  along.  The  CREATE  action  is  treated  formally  as 
an  input  action  to  the  child  transaction;  the  child  transaction  will  be  constrained  not  to  perform 
any  output  actions  until  such  a  CREATE  action  occurs.  A  consequence  of  this  method  of 
modeling  dynamic  creation  of  transactions  is  that  the  system  must  include  automata  for  all 
possible  transactions  that  might  ever  be  created  in  any  execution.  In  most  interesting  cases,  this 
means  that  the  system  will  include  infinitely  many  transaction  automata. 

In  our  work,  it  is  convenient  to  use  two  separate  actions,  REQUEST_CREATE  and  CREATE, 
to  describe  what  happens  when  a  subtransaction  is  activated.  This  separation  occurs  in  actual 
distributed  systems  such  as  Argus,  and  is  important  in  our  results  and  proofs.  Similar  remarks 
hold  for  the  distinction  among  REQUEST.COMMIT,  COMMIT  and  REPORT_COMMIT 
actions. 

3.4.  Serial  Actions 

The  external  actions  of  a  basic  system  of  a  given  system  type  include  the  serial  actions  for  that 
type.  The  serial  actions  for  a  given  system  type  are  defined  to  be  the  actions  listed  in  the 
preceding  subsection:  CREATE(T)  and  REQUEST_COMMIT(T,v),  where  T  is  any  transaction 
name  and  v  is  a  return  value,  and  REQUEST_CREATE(T),  COMMIT(T),  ABORT (T), 
REPORT_COMMIT(T,v),  and  REPORT_ABORT(T),  where  T  *  T0  is  a  transaction  name  and  v 
is  a  return  value.12  If  (3  is  a  sequence  of  actions,  define  serial^)  to  be  the  subsequence  of  (3 
containing  all  the  serial  actions  in  (3. 

In  this  subsection,  we  define  some  simple  concepts  involving  serial  actions.  All  the  definitions 
in  this  subsection  are  based  on  the  set  of  actions  only,  and  not  on  the  specific  automata  in  any 
particular  system.  For  this  reason,  we  present  these  definitions  here,  before  going  on  (in  the  next 
subsection)  to  give  more  information  about  the  basic  system  components. 

We  first  present  some  fundamental  definitions,  and  then  we  define  notions  of  “well- 
formedness”  for  sequences  of  actions. 

3.4.1.  Terminology 

The  COMMIT(T)  and  ABORT(T)  actions  are  called  completion  actions  for  T,  while  the 
REPORT_COMMIT(T,v)  and  REPORT_ABORT(T)  actions  are  called  report  actions  for  T. 

We  associate  transaction  names  with  some  of  the  serial  actions,  as  follows.  Let  T  be  a 
transaction  name.  If  n  is  cither  a  CREATE(T)  or  a  REQUEST_COMMIT(T,v)  action,  or  is  a 
REQUEST_CREATE(T’),  REPORT_COMMIT(T’,v’)  or  REPORT_ABORT(T’),  where  T’  is  a 


I2These  actions  are  called  ‘‘serial  actions”  because  they  are  exactly  the  external  actions  of  a  ‘‘serial  system” 
the  given  type.  More  will  be  said  about  serial  systems  later  in  the  paper. 
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child  of  T,  then  we  define  transaction^ k)  to  be  T.  If  n  is  a  completion  action,  then  transaction(Ti) 
is  undefined.  In  some  contexts,  we  will  also  need  to  associate  a  transaction  with  completion 
actions;  since  a  completion  action  for  T  can  be  thought  of  as  occurring  in  between  T  and 
parent(T),  some  of  the  time  we  will  want  to  associate  T  with  the  action,  and  at  other  times  we 
will  want  to  associate  parent(T)  with  it.  Thus,  we  extend  the  “transaction (it)”  definition  in  two 
different  ways.  If  Jt  is  any  serial  action,  then  we  define  hightransaction(K )  to  be  transaction^)  if 
k  is  not  a  completion  action,  and  to  be  parent(T),  if  k  is  a  completion  action  for  T.  Also,  if  x  is 
any  serial  action,  we  define  lowtransacrion(it)  to  be  transaction^)  if  n  is  not  a  completion 
action,  and  to  be  T,  if  7t  is  a  completion  action  for  T.  In  particular,  hightransaction(Tt)  = 
lowtransaction(Jt)  =  transaction(Tt)  for  all  serial  actions  7t  for  which  transaction(rt)  is  defined. 

We  also  require  notation  for  the  object  associated  with  any  serial  action  whose  transaction  is 
an  access.  If  n  is  a  serial  action  of  the  form  CREATE(T)  or  R£QUEST_COMMIT(T,v),  where 
T  is  an  access  to  X,  then  we  define  objectix)  to  be  X. 

We  extend  the  preceding  notation  to  events  as  well  as  acdons.  For  example,  if  x  is  an  event, 
then  we  write  transaction^ it)  to  denote  the  transaction  of  the  action  of  which  rt  is  an  occurrence. 
We  extend  the  definitions  of  “hightransaction,”  “lowtransaction,”  and  “object”  similarly.  We 
will  extend  other  notation  in  this  paper  in  the  same  way,  without  further  explanation. 

Now  we  require  terminology  to  describe  the  status  of  a  transaction  during  execution.  Let  (3  be 
a  sequence  of  actions.  A  transaction  name  T  is  said  to  be  active  in  p  provided  that  p  contains  a 
CREATE(T)  event  but  no  REQUEST_COMMIT  event  for  T.  Similarly,  T  is  said  to  be  live  in  P 
provided  that  P  contains  a  CREATE(T)  event  but  no  completion  event  for  T.  (However,  note 
that  P  may  contain  a  REQUEST_COMMIT  for  T.)  Also,  T  is  said  to  be  an  orphan  in  P  if  there  is 
an  ARORT(U)  action  in  P  for  some  ancestor  U  of  T. 

We  have  already  used  projection  operators  to  restrict  action  sequences  to  particular  sets  of 
actions,  and  to  actions  of  particular  automata.  We  now  introduce  another  projection  operator, 
this  time  to  sets  of  transaction  names.  Namely,  if  P  is  a  sequence  of  actions  and  t7is  a  set  of 
transaction  names,  then  pi&Hs  defined  to  be  the  sequence  pi  {it:  transaction(jt)  e  U).  If  T  is  a 
transaction  name,  we  sometimes  write  PIT  as  shorthand  for  pi{T).  Similarly,  if  P  is  a  sequence 
of  actions  and  X  is  an  object  name,  we  sometimes  write  piX  to  denote  pi  (it:  object(7t)  =  X). 

3.4.2.  Well-Formedness 

We  will  place  very  few  constraints  on  the  transaction  automata  and  basic  database  automaton 
in  our  definition  of  a  basic  system.  However,  we  will  want  to  assume  that  certain  simple 
properties  are  guaranteed;  for  example,  a  transaction  should  not  take  steps  until  it  has  been 
created,  and  the  basic  database  should  not  create  a  transaction  that  has  not  been  requested.  Such 
requirements  are  captured  by  well-formedness  conditions,  which  are  fundamental  safety 
properties  of  sequences  of  external  actions  of  the  transaction  and  basic  database  automata.  We 
define  those  conditions  here. 

First,  we  define  “transaction  well-formedness.”  Let  T  be  any  transaction  name.  A  sequence 
P  of  serial  actions  7t  with  transaction^)  =  T  is  defined  to  be  transaction  well -formed  for  T 
provided  the  following  conditions  hold. 

l.The  first  event  in  p,  if  any,  is  a  CREATE(T)  event,  and  there  are  no  other 
CREATE  events. 


17 


2.  There  is  at  most  one  REQUEST_CREATE(T’)  event  in  p  for  each  child  T’  of  T. 

3.  Any  report  event  for  a  child  T’  of  T  is  preceded  by  REQUEST_CREATE(T’)  in  {3. 

4.  There  is  at  most  one  report  event  in  (3  for  each  child  T’  of  T. 

5.  If  a  REQUEST_COMMIT  event  for  T  occurs  in  (3,  then  it  is  preceded  by  a  report 
event  for  each  child  T’  of  T  for  which  there  is  a  REQUEST_CREATE(T’)  in  p. 

6.  If  a  REQUEST_COMMIT  event  for  T  occurs  in  3,  then  it  is  the  last  event  in  p. 

In  particular,  if  T  is  an  access,  then  the  only  sequences  that  are  transaction  well-formed  for  T 
are  the  prefixes  of  the  two-event  sequences  of  the  form  CREATE(T)REQUEST_COMMI  i  (T,v;. 
For  any  T,  it  is  easy  to  see  that  the  set  of  transaction  well-formed  sequences  for  T  is  a  safety 
property,  i.e.,  that  it  is  prefix-closed  and  limit-closed. 

Next,  we  define  “basic  database  well-formedness.”  A  sequence  p  of  serial  actions  is  defined 
to  be  basic  database  well-formed  provided  the  following  conditions  hold. 

1.  The  sequence  p!T  is  transaction  well-formed,  for  all  transaction  names  T. 

2.  If  a  CREATE(T)  event  occurs  in  p,  for  T  *  Tq,  then  there  is  a  preceding 
REQUEST_CREATE(T)  in  p. 

3.  If  there  is  a  COMMIT(T)  event  in  p,  then  there  is  a  preceding 

REQUEST_COMMIT(T,v)  event  in  p,  for  some  v. 

4.  If  there  is  an  ABORT(T)  event  in  p,  then  there  is  a  preceding 

REQUEST_CREATE(T)  event  in  p. 

5.  There  is  at  most  one  completion  event  in  P  for  each  transaction  name  T. 

6.  If  there  is  a  REPORT_COMMIT(T,v)  event  in  P,  then  there  is  a  preceding 
REQUEST_COMMIT(T,v)  event  in  p  and  a  preceding  COMMIT(T)  event  in  p. 

7.  If  there  is  a  REPORT_ABORT(T)  event  in  p,  then  there  is  a  preceding  ABORT(T) 
event  in  p. 

8.  There  is  at  most  one  report  event  in  P  for  each  transaction  name  T. 


3.5.  Basic  Systems 

We  are  now  ready  to  define  “basic  systems.”  Basic  systems  are  composed  of  transaction 
automata,  one  for  each  non-access  transaction  name,  and  a  single  basic  database  automaton.  We 
describe  the  two  kinds  of  components  in  turn. 

3.5.1.  Transaction  Automata 

A  transaction  automaton  AT  for  a  non-access  transaction  name  T  (of  the  given  system  type)  is 
an  I/O  automaton  with  the  following  external  action  signature. 
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Input: 

CREATE(T) 

REPORT_COMMIT(T\v),  for  every  child  T’  of  T,  and  return  value  v 

REPORT_ABORT(T’),  for  every  child  T  of  T 

Output: 

R£QUEST_CREATE(T),  for  every  child  T*  of  T 

REQUEST_COMMIT(T,v),  for  every  return  value  v 

In  addition,  AT  may  have  an  arbitrary  set  of  internal  actions.  We  require  AT  to  preserve 
transaction  well-formedness  for  T,  as  defined  in  the  preceding  subsection.  As  discussed  earlier, 
this  does  not  mean  that  all  behaviors  of  AT  are  transaction  well-formed,  but  it  does  mean  that  as 
long  as  the  environment  of  AT  does  not  violate  transaction  well-formedness,  AT  will  not  do  so. 
Except  for  that  requirement,  transaction  automata  can  be  chosen  arbitrarily.  Note  that  if  P  is  a 
sequence  of  actions,  then  pIT  =  piext(Aj). 

Transaction  automata  are  intended  to  be  general  enough  to  model  the  transactions  defined  in 
any  reasonable  programming  language.  Particular  programming  languages  may  impose 
additional  restrictions  on  transaction  behavior.  (For  example,  Argus  suspends  activity  in 
transactions  until  subtransactions  complete.)  However,  our  results  do  not  require  such 
restrictions. 

3.5.2.  Basic  Database  Automata 

A  basic  database  automaton  is  also  modeled  as  an  I/O  automaton.  A  basic  database  passes 
requests  for  the  creation  of  subtransactions  to  the  appropriate  recipient,  initiates 
REQUEST_COMMIT  actions  for  accesses,  makes  decisions  about  the  commit  or  abort  of 
transactions,  and  passes  reports  about  the  completion  of  children  back  to  their  parents.  It  may 
also  carry  out  other  activity. 

A  basic  database  has  the  following  actions  in  its  external  action  signature. 

Input: 

REQUEST_CREATE(T),  T*T0 

REQUEST_COMMIT(T,v),  T  a  non-access  transaction  name 

Output: 

CREATE(T) 

REQUEST_COMMIT(T,v),  T  an  access  transaction  name 

COMMIT(T),T*T0 

ABORT(T),  T*T0 

REPORT_COMMIT(T,v),  T*TQ 

REPORT_ABORT(T),  T*T0 

In  addition,  it  may  have  other  arbitrary  output  actions,  as  well  as  arbitrary  internal  actions. 
Depending  upon  the  design  of  the  particular  basic  database  automaton,  some  of  the  additional 
output  actions  may  be  associated  with  particular  objects.  Hence,  each  basic  database  is  assumed 
to  come  equipped  with  an  extension  of  the  object  partial  mapping  on  actions,  which  may 
associate  some  of  these  additional,  non-serial  output  actions  with  particular  object  names.  That 
is,  each  non-serial  output  action  k  may  (but  need  not)  have  object(7t)  defined. 
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The  REQUEST_CREATE  and  REQUEST_COMMIT  inputs  are  intended  to  be  identified  with 
the  corresponding  outputs  of  transaction  automata,  and  conversely,  all  the  CREATE  and  report 
outputs  (except  those  CREATE(T)  actions  for  which  T  is  an  access)  are  identified  with  the 
corresponding  inputs  of  transaction  automata.  A  basic  database  is  required  to  preserve  basic 
database  well-formedness. 

There  are  many  examples  of  basic  databases  in  the  literature.  For  example,  the  composition  of 
the  generic  controller  and  generic  objects  of  [4]  preserves  basic  database  well-formedness,  and 
so  is  an  example  of  a  basic  database.  The  same  is  true  for  the  composition  of  the  pseudotime 
controller  and  pseudotime  objects  of  [2].  We  will  present  these  examples  in  more  detail  later  in 
this  paper.  In  fact,  we  claim  that  almost  all  interesting  transaction-processing  algorithms  can  be 
modeled  as  basic  databases.  (See  [13]  for  additional  examples.) 

Our  notion  of  basic  database  identifies  the  aspects  of  transaction-processing  algorithms  that  are 
relevant  to  our  analysis  of  orphan  management  algorithms.  It  turns  out  that  the  details  of  how 
synchronization  and  recovery  are  implemented  by  a  basic  database  are  largely  irrelevant. 
Indeed,  this  is  one  of  the  important  contributions  of  this  paper:  we  are  able  to  state  correctness 
conditions  for  and  verify  orphan  management  algorithms  in  a  way  that  is  independent  of  the 
concurrency  control  and  recovery  methods  used  within  the  basic  database. 

3.5.3.  Basic  Systems 

A  basic  system  B  is  the  composition  of  a  strongly  compatible  set  of  automata  indexed  by  the 
union  of  the  set  of  non-access  transaction  names  and  the  singleton  set  {BD}  (for  “basic 
database’’).  Associated  with  each  non-access  transaction  name  T  is  a  transaction  automaton  AT 
for  T.  Associated  with  the  name  BD  is  a  basic  database  automaton  for  the  system  type. 

When  the  particular  basic  system  B  is  understood  from  the  context,  we  call  its  external  actions 
the  basic  actions,  and  its  executions,  schedules  and  behaviors  the  basic  executions,  basic 
schedules  and  basic  behaviors,  respectively.  The  following  proposition  says  that  basic  behaviors 
have  the  appropriate  well-formedness  properties. 

Proposition  5:  If  J3  is  a  basic  behavior,  then  the  following  conditions  hold. 

1.  For  every  transaction  name  T,  (3IT  is  transaction  well-formed  for  T. 

2.  The  sequence  serial(j3)  is  basic  database  well-formt 

Proof:  Note  first  that  the  basic  database  preserves  basic  database  well-formedness, 
and  this  immediately  implies  that  it  preserves  transaction  well-formedness  for  every 
transaction  name.  Next,  note  that  each  transaction  automaton  preserves  transaction 
well-formedness  for  the  appropriate  transaction  name.  Furthermore,  it  has  in  its 
signature  no  actions  of  other  transactions,  and  so  preserves  transaction  well- 
formedness  for  all  transaction  names.  The  first  part  of  the  proposition  follows  by 
Proposition  4. 

A  simple  induction  shows  that  each  transaction  automaton  also  preserves  basic 
database  well-formedness,  and  the  second  conclusion  follows  also  from  Proposition  4. 

□ 
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3.6.  Serial  Correctness 

In  this  subsection,  we  give  appropriate  notions  of  correctness  for  basic  systems.  These  include 
notions  appropriate  for  systems  that  manage  orphans,  as  well  as  notions  for  systems  that  do  not 
manage  orphans  but  do  carry  out  concurrency  control  and  recovery.  These  notions  are  taken 
from  [11,  12,4].  The  spirit  of  our  definitions  is  similar  to  that  of  the  usual  definition  of 
“serializability”  in  the  database  literature.  However,  the  usual  notion  does  not  take  nesting  or 
aborts  into  account. 

We  define  correctness  conditions  for  basic  systems  of  a  given  type  by  relating  their  behaviors 
to  those  of  a  particular  basic  system  of  that  type,  the  “serial  system.’’  The  executions,  schedules 
and  behaviors  of  a  serial  system  are  called  “serial  executions,”  “serial  schedules”  and  “serial 
behaviors,”  respectively.  Serial  systems  are  composed  of  nansaction  automata  and  a  “serial 
database,”  which  itself  is  the  composition  of  a  “serial  scheduler”  and  objects.  The  transaction 
automata  are  identical  to  those  in  basic  systems.  The  serial  scheduler  controls  the  order  in  which 
the  transactions  take  steps  and  in  which  accesses  to  objects  occur.  It  permits  only  one  child  of  a 
transaction  to  run  at  a  time.  Thus,  sibling  transactions  execute  sequentially  at  every  parent  node 
in  the  transaction  tree,  so  that  transactions  are  run  in  a  depth-first  traversal  of  the  tree.  Also,  the 
serial  scheduler  aborts  a  transaction  only  if  it  has  not  been  created,  and  creates  a  transaction  only 
if  it  has  not  been  aborted.  Thus,  in  a  serial  execution,  sibling  transactions  execute  sequentially 
and  aborted  transaction  take  no  steps. 

Objects  in  a  serial  system  are  quite  simple.  Since  the  serial  scheduler  guarantees  that  siblings 
execute  sequentially,  and  that  aborted  transactions  never  take  any  steps,  serial  objects  do  not 
have  to  deal  with  concurrency  or  with  failures.  The  serial  objects  serve  as  a  specification  of  how 
objects  should  behave  in  the  absence  of  concurrency  and  failures.  (The  serial  objects  serve  the 
same  purpose  as  the  “serial  specifications”  in  [25,  26].)  A  detailed  description  of  serial  systems 
may  be  found  in  the  references  [11,  12,  4,  13]. 

Now  we  give  a  definition  that  says  that  a  sequence  of  actions  “looks  like”  a  serial  behavior  to 
a  particular  transaction.  Namely,  if  P  is  a  sequence  of  actions  and  T  is  a  transaction  name,  we 
say  that  [3  is  serially  correct  for  T  if  there  exists  a  serial  behavior  y  such  that  yIT  =  (3IT.  In  other 
words,  T  sees  the  same  thing  in  (3  that  it  could  see  in  some  serial  behavior. 

Now  we  can  define  two  notions  of  correctness  for  basic  systems.  First,  we  say  that  a  basic 
system  is  serially  correct  if  each  of  its  finite13  behaviors  is  serially  correct  for  all  transaction 
names.14  The  requirement  that  every  transaction  see  a  serial  view  is  very  strong.  Without 
orphan  management,  in  fact,  systems  may  not  meet  this  requirement.  (This  is  true  of  all 
published  concurrency  control  algorithms  for  nested  transactions  of  which  we  are  aware.) 
Instead,  they  provide  a  slightly  weaker  notion  of  correctness,  namely  that  non-orphan 
transactions  see  serial  views.  More  precisely,  we  say  that  a  basic  system  is  serially  correct  for 
non-orphans  if  each  of  its  finite  behaviors  (3  is  serially  correct  for  all  transaction  names  that  are 


13Serial  correctness  is  stated  in  terms  of  finite  behaviors  because  the  corresponding  property  for  infinite  behaviors 
is  not  satisfied  by  locking  algorithms,  in  the  absence  of  extra  assumptions  [22], 

14As  discussed  in  [1 1],  this  definition  of  correctness  allows  different  transactions  in  [3  to  "see”  different  serial 
behaviors.  However,  correctness  applies  to  the  root  transaction  T0  as  well,  so  the  root  must  see  the  same  results 
from  the  top-level  transactions  that  it  could  see  in  some  serial  behavior. 


21 


not  orphans  in  p.  Orphans,  however,  can  see  arbitrary  views. 

The  papers  [11,  12,  4,  2]  contain  examples  of  basic  systems  that  are  serially  correct  for  non¬ 
orphans.  The  basic  system  in  [11,  12]  uses  exclusive  locking  for  concurrency  control  and 
recovery,15  while  the  systems  in  [4]  use  a  more  general  commutativity-based  locking  strategy. 
The  systems  in  [2]  use  timestamps  for  concurrency  control  and  recovery. 

The  orphan  management  algorithms  of  this  paper  ensure  that  the  systems  that  use  them  are 
serially  correct.  To  ensure  this,  the  orphan  management  algorithms  rely  on  the  basic  database  to 
ensure  serial  correctness  for  non-orphans;  in  fact,  the  algorithms  work  with  any  basic  database 
that  ensures  serial  correctness  for  non-orphans.  In  this  sense,  the  orphan  management  algorithms 
and  the  concurrency  control  algorithms  are  independent.  We  prove  a  result  of  the  following  sort 
for  each  orphan  management  algorithm:  if  p  is  a  behavior  of  the  system  with  orphan 
management  and  T  is  a  transaction  name,  then  there  exists  a  behavior  y  of  the  underlying  basic 
system  such  that  yIT  =  pIT  and  T  is  not  an  orphan  in  y.  In  other  words,  the  orphan  management 
algorithms  prevent  transactions  from  “knowing”  that  they  are  orphans  —  everything  a 
transaction  sees  is  consistent  with  what  it  could  see  in  the  underlying  basic  system,  in  some 
execution  in  which  it  is  not  an  orphan.  These  results  imply  that  if  the  basic  system  is  serially 
correct  for  non-orphans,  then  the  corresponding  system  with  orphan  management  is  serially 
correct. 


4.  Information  Flow 

In  this  section,  we  define  families  of  irreflexive  partial  orders,  each  of  which  models  the 
information  flow  between  events  in  behaviors  of  a  basic  system.  These  partial  orders  are  used 
explicitly  by  the  orphan  management  algorithms  described  later,  in  order  to  ensure  that  no 
transaction  T  ever  obtains  knowledge  of  the  abort  of  any  of  its  ancestors.  If  this  is  the  case,  then 
there  will  always  be  a  “possible  world”  in  which  T  is  not  an  orphan  and  the  interaction  with  T 
and  its  environment  is  unchanged. 

4.1.  Families  of  Affects  Relations 

If  p  is  a  sequence  of  basic  actions,  R  is  a  binary  relation  on  events  in  p,  and  y  is  a  subsequence 
of  p,  then  we  say  that  y  is  R -closed  in  p  if,  whenever  y  contains  an  event  k  in  p,  it  also  contains 
any  event  <b  such  that  (<p,7c)  €  p. 

Let  B  be  a  basic  system,  and  let  R  =  {Rn}  be  a  family  of  relations,  one  for  each  sequence  p  of 
external  actions  of  B.  Then  R  is  said  to  be  a  family  of  affects  relations  for  B  provided  that  the 
following  conditions  hold. 

1.  Each  Rjj  is  an  irreflexive  partial  order  on  the  events  in  P  such  that  if  (0,rc)  e  Rp 
then  4>  precedes  7t  in  p. 

2.  If  y  is  a  prefix  of  P,  and  <J>  and  n  are  in  y,  then  (0,rc)  e  Rp  if  and  only  if  (0,::)  e  R^. 

3.  If  p  is  a  behavior  of  B  and  y  is  an  Rp-closed  subsequence  of  p,  then  y  is  a  behavior 


15There  are  some  minor  differences;  for  example,  the  completion  and  report  actions  are  combined  into  single 
actions  rather  than  treated  as  two  separate  actions. 
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of  B. 

4.  Suppose  that  p  is  a  behavior  of  B  and  (0,7t)  e  Ro,  where  0  is  an  ABORT(T’)  event, 
and  jc  is  a  CREATE,  a  COMMIT,  an  ABORT,  a  REPORT_COMMIT,  a 
REPORT_ABORT(T)  for  T*T’,  an  output  of  a  non-access  transaction,  or  a 
REQUEST_COMMIT  for  an  access.  Then  there  is  an  event  \\f  between  0  and  71  in 
P  such  that  (0,y)  e  Rp,  where  is  related  to  tc  as  follows: 

a.  If  jc  =  CREATE(T)  then  y  =  REQUEST_CREATE(T). 

fc.  If  jc  =  COMMIT(T)  then  y  =  REQUEST_COMMIT(T,v). 

c.  If  jc  =  REPORT_COMMIT(T,v)  then  y  =  COMMIT(T). 

d.  If  7C  =  REPORT_ABORT(T)  then  y  =  ABORT(T). 

e.  If  n  =  ABORT(T)  then  y  =  REQUEST_CREATE(T). 

f.  If  k  is  an  output  of  non-access  transaction  T,  then  y  is  an  event  of 
transaction  T. 

g.  If  K  =  REQUEST_COMMIT(T,v)  where  T  is  an  access  to  object  X,  then 
object(y)  =  X.16 

The  first  two  conditions  are  quite  simple;  the  first  says  that  each  relation  Rp  describes  a  partial 
ordering  consistent  with  the  order  in  which  events  appear  in  p,  and  the  second  says  that  whether 
or  not  one  event  affects  another  is  determined  at  the  time  the  second  event  occurs.  The  third 
condition  describes  a  sense  in  which  the  relation  Rp  captures  all  the  dependency  relationships 
between  events.  The  condition  implies  that  if  n  is  not  affected  by  0  in  some  behavior  p,  then  7t 
cannot  "know”  that  0  occurred,  since  7t  could  also  have  occurred  in  a  different  behavior  in 
which  0  did  not  occur.  The  fourth  condition  is  a  technical  condition  that  describes  certain 
limitations  on  the  pattern  of  information  flow.  It  will  be  needed  for  our  later  proofs,  and  can  be 
demonstrated  for  the  examples  in  Section  9. 

When  the  particular  family  R  =  {Rp}  of  affects  relations  is  understood,  we  will  often  refer  to 
each  Rp  as  an  "affects  relation,”  and  we  will  often  say  "0  affects  n  in  P”  to  mean  that  (0,7t)  e 
Rp. 

4.2.  Families  of  Directly-Affects  Relations 

In  many  cases  of  interest,  a  family  of  affects  relations  can  be  conveniently  described  by  a 
generating  family  of  smaller  relations.  Thus,  let  B  be  a  basic  system  and  R’  =  { R’p }  be  a  family 
of  relations,  one  for  each  sequence  P  of  external  actions  of  B.  Then  R’  is  said  to  be  a  family  of 
directly-affects  relations  for  B  provided  that  there  is  a  family  R  =  (Rp)  of  affects  relations  for  B 
such  that  for  each  P,  Rp  is  the  transitive  closure  of  R’p.  In  this  case,  we  say  that  R’  generates  R. 

When  the  particular  family  R’  =  {R’p}  of  directly-affects  relations  is  understood,  we  will  often 
refer  to  each  R’p  as  a  "directly-affects  relation”;  also,  we  will  often  say  that  "0  directly  affects 
re  in  P”  to  mean  that  (0,re)  e  R’p. 


16Note  that  vy  can  be  either  a  serial  or  a  non-serial  event. 
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4.3.  Using  Families  of  Affects  Relations  to  Describe  Orphan  Management 
Algorithms 

The  intuitive  idea  behind  the  orphan  management  algorithms  is  that  they  ensure  that  an  event 
of  a  transaction  T  is  never  affected  by  the  abort  of  an  ancestor.  Then  we  can  show  that  every 
transaction  gets  a  view  it  could  get  in  a  behavior  in  which  it  is  not  an  orphan:  we  simply  take  the 
subsequence  of  the  original  behavior  containing  all  events  of  T  and  all  events  that  affect  them  in 
that  behavior.  The  resulting  sequence  is  a  basic  behavior,  by  the  definition  of  a  family  of  affects 
relations,  and  does  not  contain  an  abort  for  an  ancestor  of  T,  by  construction. 

The  following  example  illustrates  how  an  orphan  can  see  an  inconsistent  state  in  a  system 
without  orphan  management.  Suppose  that  T  is  a  transaction  with  children  Tj  and  T->,  both  of 
which  are  accesses  to  an  object  X.  Consider  the  following  scenario:  T  first  accesses  X  through 
its  child  Tj.  T  then  requests  the  creation  of  T2,  which  will  access  X  again.  Furthermore,  assume 
that  T2  is  requested  only  if  Tj  completes  successfully,  and  that  Tj  modifies  X.  Now  suppose  that 
T  aborts  before  T2  starts  running  at  X,  and  X  learns  of  the  abort.  If  Tj’s  modification  of  X  is 
undone  when  X  learns  that  T  aborted,  then  T2  will  not  see  the  value  for  X  that  it  expects,  since 
T2  only  runs  if  Tj  has  modified  X  successfully.  This  scenario  is  captured  more  precisely  by  the 
following  fragment  of  a  schedule  of  a  generic  system  (generic  systems  are  described  in  more 
detail  in  Section  9.1): 

CREATE(T) 

REQUEST_CREATE(T! ) 

CREATE(Tj) 

REQUEST_COMMIT  (T1  ,v  j ) 

COMMIT(Ti) 

REPORT_COMMIT(T  j  ,  v  j  ) 

REQUEST_CREATE(T2) 

ABORT(T) 

INFORM_ABORT_AT(X)OF(T) 

CREATE(T2) 

REQUEST_COMMIT(T2,v2) 

(The  INFORM_ABORT  event  lets  X  know  that  T  has  aborted.)  The  family  of  affects  relations 
for  generic  systems  described  in  Section  9.1  ensures  that  the  ABORT(T)  event  affects  the 
INFORM_ABORT_AT(X)OF(T)  event,  and  that  an  event  at  an  object  is  affected  by  all  prior 
events  at  the  object.  Thus,  by  preventing  T2  from  running  when  its  events  would  be  affected  by 
the  abort  of  an  ancestor,  we  can  prevent  it  from  knowing  that  it  is  an  orphan. 


5.  Filtered  Systems 

The  two  orphan  management  algorithms  analyzed  in  this  paper  use  quite  different  techniques. 
However,  each  can  be  proved  correct  by  showing  that  it  implements  the  same  abstract  algorithm, 
described  in  this  section. 

For  Sections  5  through  8  of  this  paper,  we  fix  a  particular  but  arbitrary  basic  system  B. 
together  with  a  family  R  of  affects  relations  for  B  and  a  family  R’  of  directly-affects  relations  for 
B,  where  R’  generates  R.  We  describe  several  algorithms  that  exploit  the  properties  of  the 
affects  relations  to  manage  orphans.  In  Section  9,  we  illustrate  this  general  development  by 


describing  two  specific  basic  systems  and  their  affects  relations. 


One  way  of  ensuring  that  actions  of  a  transaction  T  are  never  affected  by  the  abort  of  an 
ancestor  of  T  is  to  add  preconditions  to  all  the  actions  of  the  basic  database  to  permit  actions  of  T 
to  occur  only  if  they  would  not  be  affected  in  this  way.  It  turns  out,  however,  that  this  approach 
checks  for  orphans  much  more  frequently  than  necessary.  In  this  section  we  define  another  kind 
of  system,  called  a  “filtered  system,”  that  checks  for  orphans  only  when  REQUEST_COMMIT 
actions  occur  for  access  transactions.  We  then  show  that  this  is  sufficient  to  ensure  that 
transactions  are  never  affected  by  the  aborts  of  ancestors. 

We  construct  a  filtered  system  based  on  the  given  basic  system  B  and  the  given  family  R  of 
affects  relations.  The  filtered  system  consists  of  the  given  transaction  automata  from  B  and  a 
“filtered  database  automaton.”  The  filtered  database  automaton  is  obtained  by  slightly 
modifying  the  basic  database  automaton;  it  “filters”  REQUEST_COMMIT  actions  of  access 
transactions  so  that  any  transaction,  orphan  or  not,  sees  a  view  it  could  see  as  a  non-orphan  in  the 
basic  system. 


5.1.  The  Filtered  Database 

The  filtered  database  is  obtained  via  a  simple  transformation  from  the  basic  database.  The 
only  difference  between  the  behaviors  of  the  two  databases  is  that  the  new  database  only  allows 
a  REQUEST_COMMIT  of  an  access  to  occur  if  it  is  not  affected  by  the  abort  of  an  ancestor. 

The  filtered  database  has  the  same  signature  as  the  basic  database.  The  state  of  the  filtered 
database  has  two  components,  basicstate  and  history,  where  basic_state  is  a  state  of  the  basic 
database  and  history  is  a  sequence  of  basic  actions.  Initial  states  of  the  filtered  database  are 
those  with  basic_state  equal  to  an  initial  state  of  the  basic  database  and  history  equal  to  the 
empty  sequence. 

A  triple  (s’,7t.s)  is  a  step  of  the  filtered  database  if  and  only  if  the  following  conditions  hold. 

1.  (s’.basic_state,7t,s.basic_state)  is  a  step  of  the  basic  database. 

2.  s. history  =  s’.historyn:  if  7t  is  a  basic  action.17 

3.  s. history  =  s’. history  if  7t  is  not  a  basic  action. 

4.  If  tt  =  REQUEST_COMMTT(T,v)  where  T  is  an  access  to  object  X,  and  if  T’  is  an 
ancestor  of  T,  then  no  ABORT(T’)  event  affects  an  event  \y  with  object(y)  =  X  in 

s’,  history. 

Thus,  at  the  point  where  the  REQUEST_COMMIT  of  an  access  is  about  to  occur,  an  explicit 
test  is  performed  to  verify  that  no  preceding  event  at  the  same  object  is  affected  by  me  abort  of 
any  ancestor  of  the  access. 

Lemma  6:  Let  P  be  a  finite  schedule  of  the  filtered  database  that  can  leave  the 

filtered  database  in  state  s.  Then  s. history  =  beh(p). 


!7RecalI  that  internal  actions  of  the  basic  database  are  not  classified  as  basic  actions. 
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5.2.  The  Filtered  System 

The  filtered  system  is  the  composition  of  the  transaction  automata  and  the  filtered  database 
automaton.  We  call  its  executions,  schedules  and  behaviors  the  filtered  executions ,  filtered 
schedules  and  filtered  behaviors,  respectively. 

Lemma  7:  The  filtered  system  implements  the  basic  system. 

Proof:  The  mapping  f  that  assigns  to  each  state  s  of  the  filtered  system  the  singleton 
set  f(s)  consisting  of  s.basic_state  is  easily  seen  to  be  a  possibilities  mapping. 
Proposition  3  implies  the  result.  □ 

As  described  above,  the  filtered  database  performs  an  explicit  test  to  ensure  that  the 
REQUEST_COMMIT  of  an  access  is  not  affected  by  the  abort  of  any  ancestor.  The  following 
key  lemma  shows  that  this  test  actually  guarantees  more:  that  a  similar  property  holds  for  all 
events. 

Lemma  8:  Let  p  be  a  filtered  behavior  and  let  T  be  any  transaction  name.  Let  p  be 
an  event  in  P  such  that  transaction(p)  =  T.  Then  there  is  no  ABORT(T’)  event  0  such 
that  (4>,p)  e  Rp,  for  any  ancestor  T’  of  T. 

Proof:  First  note  that  Lemma  7  and  Proposition  5  imply  that  serial(P)  is  basic 
database  well-formed.  The  proof  of  the  lemma  is  by  induction  on  the  length  of  p.  If  p 
is  empty,  the  result  clearly  holds.  Suppose  p  =  p’xc,  and  that  the  lemma  holds  for  p\ 
From  the  restrictions  on  affects  relations,  Rp  £  Rp.  u  {(0,7t)  I  <>  is  an  action  in  P’}. 
Thus,  by  induction,  it  suffices  to  show  that  the  lemma  holds  when  p  =  n. 

Suppose  that  the  lemma  does  not  hold,  i.e.,  that  0  =  ABORT(T’)  affects  k  in  0, 
where  transaction^)  =  T  and  T’  is  an  ancestor  of  T.  We  derive  a  contradiction.  We 
consider  cases. 

1.  T  is  a  non-access  and  n  is  an  output  action  of  T. 

Then  by  the  fourth  property  of  affects  relations,  there  is  an  event  y  of  T 
between  0  and  7t  such  that  0  affects  y  in  p\  This  contradicts  the  inductive 
hypothesis. 

2.  T  is  an  access  to  object  X  and  7t  is  a  REQUEST_COMMIT  for  T. 

Then  by  the  fourth  property  of  affects  relations,  there  is  an  event  \j/  of  object 
X  between  0  and  n  in  p’  such  that  0  affects  \\f  in  p\  Then  the  precondition  for 
n  in  the  filtered  database  is  violated,  a  contradiction. 

3.  K  is  CREATE(T). 

Then  by  the  fourth  property  of  affects  relations,  there  is  a 
REQUEST_CREATE(T)  event  y  between  0  and  7t  such  that  0  affects  y  in  P’. 

Since  REQUEST_CREATE(T)  is  an  action  of  parent(T),  the  inductive 
hypothesis  implies  that  T’  is  not  an  ancestor  of  parent(T).  The  only 
possibility  is  that  T’  =  T,  which  implies  that  ABORT(T)  precedes 
REQUEST_CREATE(T)  in  p.  But  this  implies  that  serial(P)  is  not  basic 
database  well-formed,  a  contradiction. 

4.  T  is  a  non-access  and  k  is  REPORT_COMMIT(T”,v),  where  T”  is  a  child  of 
T. 

Then  T’  is  an  ancestor  of  T”.  By  the  fourth  property  of  affects  relations,  there 
is  a  REQUEST_COMMIT(T”,v)  event  y  between  0  and  it  such  that  0  affects 
y  in  p\  Since  transaction(y)  =  T”,  this  contradicts  the  inductive  hypothesis. 
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5.  T  is  a  non-access  and  k  is  REPORT_ABORT(T”),  where  T”  is  a  child  of  T. 

By  the  fourth  property  of  affects  relations,  there  is  a 
REQUEST_CREATE(T”,v)  event  \\r  between  0  and  7t  such  that  0  affects  \|/  in 
3’.  Since  transaction^)  =  T,  this  contradicts  the  inductive  hypothesis. 

6. 7t  is  a  non-serial  basic  action. 

Then  transaction(Jt)  is  undefined,  a  contradiction. 


□ 


5.3.  Simulation  of  the  Basic  System  by  the  Filtered  System 

The  following  theorem  is  the  key  result  of  this  paper.  It  shows  that  the  filtered  system  ensures 
that  every  transaction  gets  a  view  it  could  get  in  the  basic  system  when  it  is  not  an  orphan. 
(Formally,  a  transaction  T’s  “view”  in  a  behavior  3  is  its  local  behavior,  PIT.)  In  other  words, 
an  orphan  cannot  discover  that  it  is  an  orphan,  since  the  view  it  sees  is  consistent  with  its  not 
being  an  orphan.  This  is  the  basic  correctness  property  for  the  orphan  management  algorithms. 

Theorem  9:  Let  3  be  a  filtered  behavior  and  let  T  be  a  transaction  name.  Then  there 
exists  a  basic  behavior  y  such  that  T  is  not  an  orphan  in  y  and  yIT  =  PIT. 

Proof:  Let  y  be  the  subsequence  of  3  containing  all  actions  n  such  that  transaction^) 

=  T,  and  all  other  actions  0  that  affect,  in  3,  some  action  whose  transaction  is  T.  Since 
Rg  is  a  transitive  relation,  y  is  Rg-closed  in  p.  By  the  definition  of  a  family  of  affects 
relations,  y  is  a  basic  behavior.  It  suffices  to  show  that  there  is  no  ancestor  T’  of  T  for 
which  ABORT(T’)  occurs  in  y.  Suppose  not;  i.e.,  there  exists  an  ancestor  T’  of  T  for 
which  ABORT(T’)  occurs  in  y.  Then  by  the  construction  of  y,  p  contains  an  event  7t  of 
T  such  that  an  ABORT(T)  event  0  affects  K  in  p.  By  Lemma  8,  this  is  impossible.  □ 

We  obtain  an  important  corollary  of  Theorem  9. 

Corollary  10:  If  the  basic  system  is  serially  correct  for  non-orphans,  then  the  filtered 
system  is  serially  correct.18 

Proof:  Let  3  be  a  filtered  behavior  and  let  T  be  any  transaction  name.  Theorem  9 
yields  a  behavior  5  of  the  basic  system  such  that  T  is  not  an  orphan  in  8  and  SIT  =  PIT. 
Since  the  basic  system  is  serially  correct  for  non-orphans,  there  is  a  serial  behavior  y 
with  yIT  =  8IT;  this  is  equal  to  pIT,  as  needed.  □ 

At  first  it  might  seem  somewhat  surprising  that  it  is  enough  to  prevent  the 
REQUEST_COMMIT  events  of  orphan  accesses  to  ensure  serial  correctness  for  all  orphans. 
The  reason  it  is  not  necessary  to  filter  other  actions  is  because  of  the  assumptions  about  affects 
relations.  Essentially,  these  assumptions  indicate  that  an  event,  say  CREATE(T),  cannot 
“know”  about  an  ABORT(T’)  event  unless  some  earlier  event,  in  this  case 
REQUEST_CREATE(T),  already  “knows”  about  the  ABORT(T’).  (The  assumption  about 
affects  relations  that  an  affects-closed  subsequence  of  a  behavior  is  itself  a  behavior  implies  that 
if  7t  is  not  affected  by  0,  k  cannot  know  that  0  has  occurred,  since  there  is  a  behavior  of  the 
system  in  which  rt  occurs  and  0  does  not.)  If  we  assume  inductively  that 


18It  should  be  easy  to  see  that  the  filtered  system  is  also  a  basic  system,  and  so  the  notion  of  serial  correctness  has 
been  defined  for  filtered  systems.  Similar  comments  hold  for  the  rest  of  the  systems  described  in  this  paper. 
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REQUEST_CREATE(T)  does  not  know  about  the  abort  of  an  ancestor  of  T,  then  the  properties 
assumed  for  affects  relations  guarantee  that  CREATE(T)  will  not  know  about  it  either. 

The  assumptions  about  affects  relations  derive  from  the  restricted  communication  patterns  in 
typical  systems:  a  non-access  transaction  receives  information  from  its  parent  when  it  is  created, 
and  from  its  children  when  they  report,  but  not  from  any  other  source.  Access  transactions  may 
receive  information  from  other  accesses  (e.g.,  accesses  to  the  same  object  share  state),  but  can 
only  affect  non-accesses  through  a  REPORT_COMMIT  event,  which  must  be  preceded  by  a 
REQUEST_COMMIT.  As  long  as  T  does  not  receive  reports  from  any  accesses  that  “know” 
that  its  ancestor  has  aborted,  T  cannot  observe  a  state  that  depends  on  the  abort.  In  effect,  by 
preventing  REQUEST_COMMIT  actions  for  orphan  accesses,  we  isolate  orphan  transactions 
from  the  objects,  ensuring  that  an  orphan  transaction  never  sees  that  it  is  an  orphan. 

Sometimes  we  want  to  be  explicit  about  the  dependency  of  the  filtered  system  on  the  particular 
basic  system  and  family  of  affects  relations  from  which  it  is  derived.  Thus,  we  restate  the 
corollary  above  in  a  form  that  exhibits  this  dependency.  If  B  is  a  basic  system  and  R  is  a  family 
of  affects  relations  for  B  then  let  Filtered(B,R)  be  the  corresponding  filtered  system;  it  is 
composed  of  the  same  transaction  automata  and  the  filtered  database  that  corresponds  to  the 
given  basic  database. 

Corollary  11:  Let  B  be  a  basic  system  and  R  a  family  of  affects  relations  for  B.  If  B 
is  serially  correct  for  non-orphans,  then  Filtered(B,R)  is  serially  correct. 

6.  Argus  Systems 

In  this  section  we  analyze  the  orphan  management  algorithm  used  in  the  Argus  system  [8, 9], 
We  describe  the  algorithm  by  defining  an  Argus  database  that  describes  in  formal  terms  the 
algorithm  discussed  in  [9],  As  with  the  filtered  database,  the  Argus  database  is  obtained  from 
the  basic  database  via  a  simple  construction.  We  then  define  the  Argus  system,  which  is 
composed  of  transactions  and  an  Argus  database,  and  show  that  the  Argus  system  implements 
the  filtered  system.  Thus,  if  the  filtered  system  is  serially  correct,  so  is  the  corresponding  Argus 
system. 

6.1.  The  Argus  Database 

The  filtered  database  uses  global  knowledge  of  the  entire  history  of  actions  to  filter  the 
REQUEST_COMMIT  actions  of  access  transactions.  This  kind  of  global  knowledge  is  not 
practical  in  a  distributed  system.  Thus,  the  Argus  algorithm  makes  use  of  local  knowledge  about 
the  aborts  that  have  occurred.  To  ensure  that  the  REQUEST_COMMIT  of  an  access  is  not 
affected  by  the  abort  of  an  ancestor,  the  Argus  algorithm  keeps  track  of  the  aborts  “known”  by 
each  event  that  occurs,  and  propagates  this  knowledge  from  an  event  to  any  later  events  that  it 
affects. 

In  the  actual  Argus  system,  knowledge  about  aborts  is  propagated  in  messages  sent  over  the 
network;  we  model  this  formally  by  propagating  knowledge  from  an  event  to  every  event  that  it 
directly  affects.  A  poor  choice  of  a  directly-affects  relation  could  make  the  algorithm  we 
describe  here  hard  to  implement.  However,  if  one  event  0  directly  affects  another  event  7t  only  if 
the  two  events  occur  at  the  same  site,  or  if  a  message  is  sent  from  0's  site  to  7t’s  after  0  occurs 
and  before  k  occurs,  then  it  is  straightforward  to  implement  the  algorithm  using  information 
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available  locally  at  each  site,  by  transmitting  the  information  about  aborted  transactions  on 
messages  sent  between  sites. 

The  construction  of  the  Argus  database  makes  use  of  the  given  family  R’  of  directly-affects 
relations  for  B.  The  Argus  database  has  the  same  signature  as  the  basic  database.  The  state  of 
the  Argus  database  has  three  components:  basic  state,  history  and  known_aborts,  where 
basic_state  is  a  state  of  the  basic  database,  history  is  a  sequence  of  basic  actions,  and 
known_aborts  is  a  partial  mapping  from  basic  events  to  sets  of  transactions.  This  mapping 
records  the  transactions  whose  aborts  affect  each  event  that  has  occurred.  The  set 
known_aborts(;t)  may  actually  include  more  transactions  than  those  whose  aborts  affect  7t.  By 
adding  more  aborted  transactions  to  this  set,  an  implementation  would  restrict  the  behavior  of 
orphans  further  than  is  stricdy  necessary  to  ensure  the  correctness  conditions.19  In  Argus,  for 
example,  each  event  occurs  at  some  physical  node  of  the  network,  and  each  node  manages  a 
single  set  of  aborted  transactions  for  the  entire  set  of  events  that  occur  at  that  node.  In  this  case, 
known_aborts(7t)  includes  at  least  the  transactions  whose  aborts  affect  7t,  as  well  as  those 
transactions  whose  aborts  affect  any  other  event  that  has  occurred  at  the  same  physical  node  as  7t. 

Initial  states  of  the  Argus  database  are  those  with  basic_state  equal  to  an  initial  state  of  the 
basic  database,  history  equal  to  the  empty  sequence,  and  known_aborts  everywhere  undefined. 
A  triple  (s’,;c,s)  is  a  step  of  the  Argus  database  if  and  only  if  the  following  conditions  hold. 

1.  (s’.basic_state,7t,s.basic_state)  is  a  step  of  the  basic  database. 

2.  s. history  =  s’.history7t  if  K  is  a  basic  action. 

3.  s.history  =  s’. history  if  tc  is  not  a  basic  action. 

4.  If  k  is  a  basic  action  and  (<j>,Tt)  €  R’S-history  ^en  s\known_aborts(<j))  c 
s.  known_aborts(7t) . 

5.  If  4>  *  tc,  then  s.known_aborts(<j>)  =  s’.known_aborts(<j>). 

6.  If  tc  is  a  basic  action  and  0  is  an  ABORT(T)  event  in  s’. history  such  that  (0,tc)  e 
R’ s'  history  tlien  T  e  s.known_aborts(7t). 

7.  If  tc  is  a  REQUEST_COMMIT(T,v)  action  for  an  access  T  to  object  X,  then  there 
is  no  ancestor  of  T  in  s’.known_aborts(<J>),  for  any  event  0  of  object  X  in  s’. history. 

There  are  two  significant  differences  between  the  Argus  database  and  the  basic  database. 
First,  the  effects  for  each  action  7t  in  the  Argus  database  require  s.known_aborts(Tt)  to  include 
s’.known_aborts(<J))  for  each  <}>  that  directly  affects  tc.  In  addition,  an  event  n  that  is  directly 
affected  by  ABORT(T)  requires  T  to  be  in  known_aborts(Tc).  As  Lemma  16  below  shows,  these 
constraints  are  enough  to  ensure  that  s.known_aborts(7t)  contains  T  whenever  ABORT(T)  affects 

TC. 


Second,  the  precondition  for  the  REQUEST_COMMIT  of  an  access  to  X  permits  the  event  to 


19In  fact,  our  description  does  not  require  the  known_aborts  set  for  an  event  to  contain  only  aborted  transactions. 
Adding  non-aborted  transactions  to  the  set  might  cause  non-orphans  to  block,  but  will  otherwise  not  result  u; 
incorrect  behavior.  One  might  like  to  prove  that  a  system  does  not  treat  a  non-orphan  as  an  orphan;  as  with  other 
liveness  properties,  we  do  not  address  this  issue  here. 
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occur  only  if  the  access  does  not  “know  about”  the  abort  of  an  ancestor,  i.e.,  no  ancestor  is  in 
s’.known_aborts(<)))  for  any  event  0  of  object  X  in  s’.history.  As  Lemma  17  below  shows,  this  is 
enough  to  ensure  that  every  Argus  behavior  is  a  filtered  behavior. 

The  known_aborts  mapping  models  the  distributed  information  maintained  by  the  Argus 
algorithm  to  keep  track  of  actions  that  abort.  However,  rather  than  modeling  nodes  directly  and 
keeping  the  information  on  a  per-node  basis  as  is  done  in  the  actual  algorithm,  we  maintain  the 
information  for  each  event,  propagating  it  whenever  one  event  directly  affects  another. 

The  known_aborts  component  is  managed  so  as  to  insure  that  at  least  the  minimum  amount  of 
necessary  information  is  propagated  at  each  step.  An  implementation  is  permitted  to  propagate 
more  than  the  minimum;  for  instance,  an  implementation  might  keep  track  of  the  known_aborts 
mapping  at  a  coarser  granularity.  (By  maintaining  the  known_aborts  mapping  on  a  per-node 
basis,  the  implementation  of  the  Argus  algorithm  in  the  current  Argus  prototype  follows  this 
strategy.)  In  describing  the  algorithm,  we  have  tried  to  focus  on  the  behavior  necessary  for 
correctness,  and  to  avoid  constraining  an  implementation  any  more  than  necessary. 

Notice  also  that  the  Argus  database  does  not  put  any  upper  limit  on  what  goes  into  the 
known_aborts  mapping.  For  example,  as  described  above  it  is  permissible  for  known_aborts(7t) 
to  contain  a  transaction  that  has  not  aborted.  It  would  be  easy  (and  intuitively  appealing)  to  add 
a  requirement  that  known_aborts(re)  only  includes  aborted  transactions,  but  this  is  not  necessary 
to  prove  that  the  algorithm  prevents  all  orphans  from  seeing  inconsistent  views.  To  prove  other 
properties,  such  as  that  the  algorithm  only  detects  real  orphans,  we  would  need  to  add  additional 
requirements  such  as  the  one  just  mentioned.  We  will  not  attempt  to  state  or  prove  such 
properties  in  this  paper,  the  property  just  described  is  a  special  case  of  more  general  liveness 
properties,  which  are  an  appropriate  subject  of  further  research. 

Finally,  while  the  Argus  database  is  distinguished  from  the  filtered  database  by  maintaining 
information  about  ABORT  actions  on  a  more  local  basis,  we  have  kept  the  state  component 
s.history,  which  maintains  global  knowledge  of  the  past  behavior  of  the  system.  A  practical 
implementation  of  this  algorithm  would  maintain  less  voluminous  history  information  in  a 
distributed  fashion.  Examination  of  the  additional  preconditions  imposed  by  the  Argus  database 
on  any  action  re  reveals  that  s.history  is  used  to  determine  the  events  0  that  directly  affect  re,  and 
when  re  is  a  REQUEST_COMMIT(T,v)  action  for  an  access  T  to  object  X,  to  determine  the 
events  that  precede  re  at  X.  The  details  of  efficient  maintenance  of  sufficient  history  information 
are  dependent  on  the  particular  basic  database  and  distribution  scheme,  and  are  not  addressed 
further  in  this  paper. 


6.2.  The  Argus  System 

The  Argus  system  is  the  composition  of  transactions  and  the  Argus  database.  Executions, 
schedules  and  behaviors  of  the  Argus  system  are  called  Argus  executions,  Argus  schedules  and 
Argus  behaviors,  respectively. 

Lemma  12:  The  Argus  system  implements  the  basic  system. 

Proof:  The  proof  is  similar  to  that  of  Lemma  7.  □ 

Lemma  13:  Let  p  be  a  finite  Argus  behavior  that  can  leave  the  Argus  database  in 
state  s.  Then  s.known_aborts(re)  is  defined  if  and  only  if  re  is  an  event  in  p. 
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The  following  lemma  says  that  each  known_aborts  set  is  defined  at  most  once  during  an  Argus 
execution. 

Lemma  14:  Let  [3’ (3  be  a  finite  Argus  schedule,  where  (3*  can  leave  the  Argus 
database  in  state  s’  and  (s’,p,s)  is  an  extended  step  of  the  Argus  database.  If 
s’.known_aborts(Tt)  is  defined,  then  s’.known_aborts(Tt)  =  s.known_aborts(Tt). 

The  next  lemma  says  that  the  known_aborts  set  for  an  event  tc  includes  all  events  that  directly 
affect  7t,  and  that  the  known_aborts  set  for  tc  includes  T  if  tc  is  directly  affected  by  an  ABORT(T) 
event. 

Lemma  15:  Let  (3  be  a  finite  Argus  behavior  that  can  leave  the  Argus  database  in 
state  s. 

1.  If  0  and  tc  are  events  in  (3  such  that  0  directly  affects  7t  in  p,  then 
s.known_aborts(0)  c  s.known_aborts(Tc). 

2.  If  tc  is  directly  affected  by  an  ABORT(T)  event  in  P  then  T  e 
s.known_aborts(TC). 

Proof:  Immediate  by  the  definition  of  the  Argus  database  steps  and  Lemmas  13  and 
14.  □ 

The  next  lemma  is  the  key  to  the  proof  of  correctness  for  the  Argus  system:  it  says  that  the 
known_aborts  set  for  an  event  tc  includes  all  transactions  T  such  that  an  ABORT(T)  event  affects 
tc.  In  other  words,  the  Argus  database  propagates  enough  information  about  aborts  so  that  every 
event  tc  “knows  about”  (stores  in  s.known_aborts(Tt))  every  abort  that  affects  it. 

Lemma  16:  Let  P  be  a  finite  Argus  behavior  that  can  leave  the  Argus  database  in 
state  s.  If  0  and  tc  are  events  in  P  such  that  <|>  affects  tc  in  P  and  <(>  is  an  ABORT(T) 
event,  then  T  e  s.known_aborts(TC). 

Proof:  The  proof  proceeds  by  induction  on  the  length  of  the  chain  in  the  directly- 
affects  relation  by  which  0  affects  tc  in  p.  If  the  length  of  the  chain  is  1,  then  0  directly 
affects  tc  in  p.  Then  Lemma  15  implies  thatT  e  s.known_aborts(Tc). 

Now  suppose  that  the  length  of  the  chain  is  k+1,  where  k  >  1.  Then  there  is  an  event 
\\r  in  psuch  that  0  affects  y  in  P  by  a  chain  of  length  at  most  k  and  \f  directly  affects  tc 
in  p.  By  inductive  hypothesis,  T  e  s.known_aborts(y).  Lemma  15  implies  that 
s.known_aborts(y)  c  s.known_aborts(Tt),  so  that  T  e  s.known_aborts(Tc).  □ 


6.3.  Simulation  of  the  Basic  System  by  the  Argus  System 

The  following  lemma  shows  that  the  information  in  known_aborts,  combined  with  the 
precondition  on  REQUEST_COMMIT  actions  for  accesses,  is  enough  to  ensure  that  the  Argus 
system  implements  the  filtered  system. 

Lemma  17:  The  Argus  system  implements  the  filtered  system. 

Proof:  We  define  a  mapping  f  that  assigns  to  each  state  s  of  the  Argus  system  the 
singleton  set  f(s)  consisting  of  the  state  of  the  filtered  system  that  is  the  same  except 
for  the  omission  of  the  s.known_aborts  component  of  the  Argus  database  state.  We 
must  show  that  f  is  a  possibilities  mapping.  Condition  1.  is  easy  to  check.  For 
condition  2.,  suppose  that  s’  is  a  reachable  state  of  the  Argus  system,  f  e  f(s’)  is  a 
reachable  state  of  the  filtered  system,  and  (s’,7t,s)  is  a  step  of  the  Argus  system.  The 
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only  interesting  case  to  check  is  when  n  =  REQUEST_COMMIT(T,v),  where  T  is  an 
access  to  an  object  X.  In  this  case,  we  claim  that  (t’,7t,t)  is  a  step  of  the  filtered  system, 
where  t  is  the  single  element  of  f(s). 

To  show  that  (t’,7t,t)  is  a  step  of  the  filtered  system,  we  must  show  the  four 
conditions  defining  these  steps.  The  first  three  are  immediate  from  the  definition  of 
the  steps  of  the  Argus  database.  To  see  the  fourth,  suppose  that  T’  is  an  ancestor  of  T. 

We  must  show  that  no  ABORT(T’)  event  affects  an  event  of  object  X  in  t\ history. 
Suppose  the  contrary,  that  an  ABORT(T’)  event  0  affects  an  event  \j/  of  object  X  in 
t’.history.  Then  0  also  affects  y  in  s’.history.  By  Lemma  16,  T’  e  s.known_aborts(\j/). 

But  this  violates  the  precondition  for  rc  in  the  Argus  database.  Therefore,  n  is  enabled 
int’.  □ 

The  following  theorem  shows  that  Argus  systems,  like  filtered  systems,  ensure  that  every  non- 
access  transaction  gets  a  view  it  could  get  in  an  execution  in  which  it  is  not  an  orphan. 

Theorem  18:  .  Let  (3  be  an  Argus  behavior  and  let  T  be  a  transaction  name.  Then 
there  exists  a  basic  behavior  y  such  that  T  is  not  an  orphan  in  y  and  yIT  =  piT. 

Proof:  Immediate  by  Lemma  17  and  Theorem  9.  □ 

As  for  the  filtered  system,  we  obtain  an  important  corollary  about  serial  correctness. 

Corollary  19:  If  the  basic  system  is  serially  correct  for  non-orphans,  then  the  Argus 
system  is  serially  correct. 

Again,  we  give  a  version  of  the  preceding  corollary  in  which  the  dependency  of  the  Argus 
system  on  the  basic  system  is  made  explicit.  If  B  is  a  basic  system  and  R’  is  a  family  of  directly- 
affects  relations  for  B,  then  let  Argus(B,R’)  be  the  corresponding  Argus  system;  it  is  composed 
of  the  same  transaction  automata  and  the  Argus  database  that  is  constructed  from  the  given  basic 
database,  using  the  given  family  of  relations  R’. 

Corollary  20:  Suppose  B  is  a  basic  system  and  R’  is  a  family  of  directly-affects 
relations  for  B.  If  B  is  serially  correct  for  non-orphans,  then  Argus(B,R’)  is  serially 
correct. 

7.  Strictly  Filtered  Systems 

The  orphan  management  algorithm  described  in  [16]  actually  ensures  a  stronger  property  than 
does  the  Argus  algorithm.  It  ensures  that  REQUEST_COMMIT  can  never  occur  for  an  orphan 
access,  whereas  the  Argus  algorithm  merely  ensures  that  no  such  REQUEST_COMMIT  can 
occur  if  the  access  can  “observe”  that  it  is  an  orphan.  In  this  section  we  define  the  “strictly 
filtered  database,”  which  allows  a  REQUEST_COMMIT  to  occur  for  an  access  only  if  no 
ancester  has  aborted.  (Compare  this  to  the  filtered  database,  which  allows  an  access  to 
REQUEST_COMMIT  if  an  ancestor  has  aborted  as  long  as  the  access  is  not  affected  by  the 
a^ort.)  We  then  define  the  strictly  filtered  system,  which  is  composed  of  transactions  and  the 
stiictly  filtered  controller,  and  show  that  the  strictly  filtered  system  implements  the  filtered 
system.  In  the  next  section  we  will  describe  formally  the  algorithm  from  [16]  and  show  that  it 
implements  the  stricdy  filtered  system. 
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7.1.  The  Strictly  Filtered  Database 

The  strictly  filtered  database  is  similar  to  the  filtered  database;  it  has  the  same  actions,  and  the 
same  states.  A  triple  (s’,Jt,s)  is  a  step  of  the  strictly  filtered  database  if  and  only  if  the  following 
conditions  hold. 

1.  (s’.basic_state,7t,s.basic_state)  is  a  step  of  the  basic  database. 

2.  s.history  =  s’.historyit  if  it  is  a  basic  action. 

3.  s.history  =  s’. history  if  k  is  not  a  basic  action. 

4.  If  k  =  REQUEST_COMMIT(T,v)  where  T  is  an  access,  and  T’  is  an  ancestor  of  T, 
then  no  ABORT(T’)  event  occurs  in  s’.history. 

Thus,  at  the  point  where  the  REQUEST_COMMIT  of  an  access  is  about  to  occur,  an  explicit 
test  is  performed  to  verify  that  there  is  no  preceding  abort  of  any  ancestor  of  the  access. 


7.2.  The  Strictly  Filtered  System 

The  strictly  filtered  system  is  the  composition  of  transactions  and  the  strictly  filtered  database. 
Executions,  schedules  and  behaviors  of  the  strictly  filtered  system  are  strictly  filtered  executions, 
schedules  and  behaviors,  respectively. 

Lemma  21:  The  strictly  filtered  system  implements  the  basic  system. 

Proof:  The  proof  is  similar  to  that  of  Lemma  7.  □ 


7.3.  Simulation  of  the  Basic  System  by  the  Strictly  Filtered  System 

Lemma  22:  The  strictly  filtered  system  implements  the  filtered  system. 

Proof:  We  define  a  mapping  f  that  assigns  to  each  state  s  of  the  strictly  filtered 
system  the  singleton  set  f(s)  that  consists  of  the  same  state.  We  must  show  that  f  is  a 
possibilities  mapping.  Condition  1.  is  easy  to  check.  For  condition  2.,  suppose  that  s’ 
is  a  reachable  state  of  the  strictly  filtered  system,  t’  e  f(s’)  is  a  reachable  state  of  the 
filtered  system,  and  (s’,7t,s)  is  a  step  of  the  strictly  filtered  system.  As  before,  the  only 
interesting  case  to  check  is  when  n  =  REQUEST_COMMIT(T,v),  where  T  is  an  access 
to  an  object  X.  In  this  case,  we  claim  that  (t’,7t,t)  is  a  step  of  the  filtered  system,  where 
t  is  the  unique  element  of  f(s). 

To  show  that  (t’,7t,t)  is  a  step  of  the  filtered  system,  we  must  show  the  four 
conditions  defining  these  steps.  The  first  three  are  immediate  from  the  definition  of 
the  steps  of  the  strictly  filtered  database.  To  see  the  fourth,  suppose  that  T’  is  an 
ancestor  of  T.  We  must  show  that  no  ABORT(T’)  event  affects  an  event  of  object  X  in 
t\ history.  But  t’.history  =  s’.history,  and  by  the  preconditions  for  it  in  the  strictly 
filtered  database,  no  ABORT(T’)  event  occurs  in  s’.history.  Therefore,  no 
ABORT(T’)  event  affects  an  event  of  object  X  in  t’.history.  Thus,  k  is  enabled  in  t’.  □ 

Strictly  filtered  systems,  like  filtered  systems  and  Argus  systems,  prevent  orphans  from 
discovering  that  they  are  orphans. 

Theorem  23:  Let  (3  be  a  strictly  filtered  behavior  and  let  T  be  a  transaction  name. 

Then  there  exists  a  basic  behavior  y  such  that  T  is  not  an  orphan  in  y  and  yIT  =  (3!T. 

Proof:  Immediate  by  Lemma  22  and  Theorem  9.  □ 
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Corollary  24:  If  the  basic  system  is  serially  correct  for  non-orphans,  then  the  strictly 
filtered  system  is  serially  correct. 

If  B  is  a  basic  system,  let  Strictly-Filtered(B)  be  the  corresponding  strictly  filtered  system;  it  is 
composed  of  the  same  transaction  automata  and  the  strictly  filtered  database  that  corresponds  to 
the  given  basic  database. 

Corollary  25:  Suppose  that  B  is  a  basic  system.  If  B  is  serially  correct  for  non¬ 
orphans  then  Strictly-Filtered(B)  is  serially  correct. 

8.  Clocked  Systems 

In  this  section  we  describe  formally  the  orphan  management  algorithm  from  [16].  (The 
algorithm  described  here  actually  generalizes  the  one  described  in  [16].  The  algorithm  in  [16] 
delays  commits  of  transactions,  as  well  as  aborts,  while  the  algorithm  described  here  delays  only 
aborts.  A  similar  generalization  is  described  in  [17].)  We  do  this  by  defining  the  “clocked 
database,”  which  uses  a  global  clock  to  ensure  that  transactions  do  not  abort  until  all  their 
descendant  accesses  have  stopped  running.  We  then  define  the  clocked  system,  which  is 
composed  of  transactions  and  the  clocked  database.  Finally,  we  show  that  the  clocked  system 
implements  the  strictly  filtered  system,  and  thus  simulates  the  basic  system  in  the  same  way  as 
the  previously  mentioned  systems  do. 

8.1.  The  Clocked  Database 

The  clocked  database  maintains  a  quiesce  time  for  each  access  transaction  and  a  release  time 
for  every  transaction.  An  access  transaction  is  allowed  to  REQUEST_COMMIT  only  if  its 
quiesce  time  has  not  passed.  Release  times  are  chosen  so  that  once  a  transaction’s  release  time  is 
reached,  all  its  descendant  accesses  have  quiesced.  A  transaction  is  allowed  to  abort  only  if  its 
release  time  has  passed.  This  ensures  that,  after  a  transaction  aborts,  none  of  its  descendant 
accesses  will  request  to  commit. 

If  quiesce  and  release  times  are  fixed  in  advance,  some  transactions  may  be  forced  to  abort 
unnecessarily  as  their  quiesce  times  expire,  and  aborts  may  need  to  be  delayed  until  release  times 
are  reached.  It  is  possible  to  obtain  extra  flexibility  by  providing  actions  in  the  clocked  database 
for  adjusting  quiesce  and  release  times. 

The  action  signature  of  the  clocked  database  is  the  same  as  that  of  the  basic  database,  except 
that  the  clocked  database  has  three  additional  kinds  of  internal  actions.  The  new  actions  are: 

Internal  Actions: 

TICK 

ADJUST_QUIESCE(T),  T  an  access 

ADJUST_RELEASE(T),  T  any  transaction 

The  TICK  action  advances  the  clock,  while  the  two  ADJUST  actions  adjust  quiesce  and 
release  times.  By  adjusting  the  quiesce  time  for  a  transaction  to  be  later  than  its  current  value, 
we  can  extend  the  time  during  which  a  transaction  is  allowed  to  run.  Similarly,  by  adjusting  the 
release  time  for  a  transaction  to  be  earlier  than  its  current  value,  we  can  allow  a  transaction  to 
abort  without  waiting  as  long  as  would  otherwise  be  necessary. 
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The  state  of  the  clocked  database  consists  of  components  basic_state ,  aborted,  clock ,  quiesce, 
and  release.  Here,  basic_state  is  a  state  of  the  basic  database,  initialized  at  an  initial  state  of  the 
basic  database.  The  component  aborted  is  a  set  of  transactions,  initially  empty.  The  component 
clock  is  a  real  number,  initialized  arbitrarily.  The  component  quiesce  is  a  total  mapping  from 
access  transaction  names  to  real  numbers,  and  the  component  release  is  a  total  mapping  from  all 
transaction  names  to  real  numbers.  The  initial  values  of  quiesce  and  release  are  arbitrary,  subject 
to  the  following  condition:  for  all  transaction  names  T  and  T\  where  T  is  an  access  and  T’  is  an 
ancestor  of  T,  quiesce(T)  <  release(T’). 

A  triple  (s’,7t,s)  is  a  step  of  the  clocked  database  if  and  only  if  the  following  conditions  hold. 

1.  If  7t  is  an  action  of  the  basic  system,  then  (s’.basic_state,7t,s.basic_state)  is  a  step  of 
the  basic  database. 

2.  If  ;t  is  a  TICK,  ADJUST_QUIESCE  or  ADJUST_RELEASE  action,  then 
s.basic_state  =  s’.basic_state. 

3.  If  k  =  ABORT (T)  then 

a.  s. aborted  =  s’. aborted  u  {T}. 

b.  s’.release(T)  <  s’.clock. 

4.  If  k  is  not  an  abort  action,  then  s. aborted  =  s’. aborted. 

5.  If  rc  =  REQU£ST_COMMIT(T,v)  where  T  is  an  access,  then  s’.clock  < 
s’.quiesce(T). 

6.  If  k  =  TICK  then  s’.clock  <  s.clock. 

7.  If  7t  is  not  a  TICK  action,  then  s.clock  =  s’.clock. 

8.  If  7t  =  AD JU ST_RELE ASE(T)  then 

a.  if  T  €  s’. aborted  then  s.release(T)  <  s’.clock, 

b.  s’.quiesce(T’)  <  s.release(T)  for  all  T’  e  descendants(T)  n  accesses,  and 

c.  s.release(T’)  =  s’.release(T’)  for  all  T’  *  T. 

9.  If  7t  is  not  an  ADJUST_RELEASE  action,  then  s. release  =  s’.release. 

10.  If  7t  =  ADJUST_QUIESCE(T)  then 

a.  s.quiesce(T)  ^  s’.release(T’)  for  all  T’  e  ancestors(T),  and 

b.  s.quiesce(T’)  =  s’.quiesce(T’)  for  all  T’  *  T. 

11.  If  rc  is  not  an  ADJUST_QUrESCE  action,  then  s. quiesce  =  s’. quiesce. 

Lemma  26:  Let  (3  be  a  finite  schedule  of  the  clocked  database  that  can  leave  the 
clocked  database  in  state  s. 

1.  If  T  €  s. aborted  then  s.release(T)  <  s.clock. 

2.  For  all  accesses  T  and  all  ancestors  T’  of  T,  s.quiesce(T)  <  s.release(T'). 

Proof:  Straightforward  by  induction.  □ 
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8.2.  The  Clocked  System 

The  clocked  system  is  the  composition  of  transactions  and  the  clocked  database.  External 
actions  of  the  clocked  system  are  called  clocked  actions.  Executions,  schedules  ^nd  behaviors  of 
a  clocked  system  are  called  clocked  executions,  schedules  and  behaviors ,  respectively. 

Lemma  27:  The  clocked  system  implements  the  basic  system. 

Proof:  The  proof  is  similar  to  that  of  Lemma  7.  □ 


8.3.  Simulation  of  the  Basic  System  by  the  Clocked  System 

Lemma  28:  The  clocked  system  implements  the  strictly  filtered  system. 

Proof:  We  define  a  mapping  f  that  assigns  to  each  state  s  of  the  clocked  system  the 
set  f(s)  of  states  t  of  the  strictly  filtered  system  such  that  t.basic_state  =  s.basic_state 
and  t.history  is  a  sequence  of  basic  actions  in  which  the  set  of  transaction  names  T  for 
which  ABORT(T)  occurs  in  t.history  is  exactly  s.aborted.  We  must  show  that  f  is  a 
possibilities  mapping.  Condition  1.  is  easy  to  check.  For  condition  2.,  suppose  that  s’ 
is  a  reachable  state  of  the  clocked  system,  f  e  f(s’)  is  a  reachable  state  of  the  strictly 
filtered  system  and  (s’,7t,s)  is  a  step  of  the  clocked  system. 

There  are  two  interesting  cas^"  to  check:  where  n  =  ABORT(T)  and  where  k  = 
REQUEST_COMMIT(T,v)  for  an  access  T.  In  either  case,  we  claim  that  (f  ,7t,t)  is  a 
step  of  the  strictly  filtered  system,  where  t  is  the  state  of  the  strictly  filtered  system  in 
which  t.basic_state  =  s.basic_state  and  t.history  =  t’.historyTt,  and  we  also  claim  that  t 
e  f(s). 

If  7t  =  ABORT(T),  it  is  easy  to  see  that  (f  ,7t,t)  is  a  step  of  the  strictly  filtered  system. 

To  show  t  e  f(s),  note  that  since  f  e  f(s’),  the  set  of  transaction  names  U  for  which 
ABORT(U)  occurs  in  f. history  is  exactly  s ’.aborted.  Then  the  set  of  transaction 
names  with  aborts  in  t.history  is  exactly  s’. aborted  u  {Tl,  which  is  equal  to  s.aborted. 
Thus,  t  e  f(s). 

If  k  =  REQUEST_COMMIT(T,v),  where  T  is  an  access,  then  it  is  easy  to  see  the 
first  three  conditions  of  the  definition  of  strictly  filtered  database  steps.  For  the  fourth 
condition,  we  must  show  that  if  T’  is  an  ancestor  of  T,  then  no  ABORT(T’)  event 
occurs  in  t’. history.  So  suppose  the  contrary,  that  T’  is  an  ancestor  of  T  and 
ABORT(T’)  occurs  in  f  .history.  Since  t’  e  f(s’),  we  have  T’  e  s’. aborted.  Since  n  is 
enabled  in  s’,  s’. clock  <  s’.quiesce(T).  Lemma  26  implies  that  s’.release(T’)  <  s’. clock 
and  also  that  s’.quiesce(T)  <  s’.release(T’).  Thus,  s’.quiesce(T)  <  s’. clock,  a 
contradiction.  It  follows  that  (t’,7t,t)  is  a  step  of  the  strictly  filtered  system. 

Since  t’  e  f(s’),  the  set  of  transaction  names  U  for  which  ABORT(U)  occurs  in 
t’. history  is  exactly  s’. aborted.  Then  the  set  of  transaction  names  with  aborts  in 
t.history  is  exactly  s’. aborted  =  s.aborted.  Thus,  tef(s).  □ 

Theorem  29:  Let  p  be  a  clocked  behavior  and  let  T  be  a  transaction  name.  Then 
there  exists  a  basic  behavior  y  such  that  T  is  not  an  orphan  in  y  and  yIT  =  (3 IT. 

Proof:  By  Lemma  28  and  Theorem  23.  □ 

Corollary  30:  If  the  basic  system  is  serially  correct  for  non-orphans,  then  the 
clocked  system  is  serially  correct. 

If  B  is  a  basic  system,  then  let  CIocked(B)  be  the  corresponding  clocked  system;  it  is 
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composed  of  the  same  transaction  automata  and  the  clocked  database  of  the  appropriate  type. 

Corollary  31:  Suppose  B  is  a  basic  system.  If  B  is  serially  correct  for  non-orphans, 
then  Clocked(B)  is  serially  correct. 

The  algorithm  described  here  uses  a  single  physical  clock  to  detect  and  eliminate  orphans.  The 
algorithm  can  be  adapted  to  work  with  distributed,  loosely  synchronized  physical  clocks,  or  with 
logical  clocks  (e.g.,  see  [17]).  The  adapted  algorithms  can  be  described  and  analyzed  in  a 
manner  similar  to  that  used  for  the  Argus  algorithm. 

9.  Examples 

In  this  section,  we  describe  two  important  kinds  of  basic  systems,  together  with  a  family  of 
affects  relations  (and  a  generating  family  of  directly-affects  relations)  foi  each  of  them.  The  first 
kind  of  system  is  a  “generic  system.’’  It  is  suitable  for  modeling  locking  algorithms  and  has 
been  studied  in  [4],  The  second  is  a  “pseudotime  system.’’  It  is  suitable  for  modeling 
timestamp  algorithms  and  has  been  studied  in  [2]. 


9.1.  Generic  Systems 

A  generic  system  consists  of  a  collection  of  transaction  automata,  one  for  each  non-access 
transaction  name,  a  collection  of  “generic  object  automata,”  one  for  each  object  name,  and  a 
single  “generic  controller  automaton.”  The  interactions  between  the  components  are  as  follows. 

The  transaction  interface  is  exactly  as  before.  The  generic  object  automaton  for  X  has 
CREATE(T)  input  actions  and  REQUEST_COMMIT(T,v)  output  actions  for  each  access  T  to  X 
and  each  return  value  v.  It  also  has  INFORM_COMMIT_AT(X)OF(T)  and 
INEORM_ABORT_AT(X)OF(T)  input  actions  fee  each  transaction  T;  these  actions  inform  the 
object  X  of  the  fates  (commit  or  abort)  of  completed  transactions.  The  object  uses  this 
information  in  carrying  out  concurrency  control  and  recovery;  for  example,  an 
INFORM_ABORT  of  T  might  cause  the  object  to  release  locks  held  by  T. 

The  external  actions  of  the  generic  controller  are  similar  to  those  required  of  all  basic 
databases:  it  has  the  inputs  and  outputs  required  of  a  basic  database,  except  that 
REQUEST_COMMIT  actions  for  access  transactions  are  inputs  to  the  generic  controller;  in 
addition,  it  has  INFORM_COMMIT  and  INFORM_ABORT  actions  as  outputs. 

We  model  the  generic  controller  as  a  specific  automaton,  particular  to  the  system  type.  The 
object  automata,  however,  like  the  transaction  automata,  are  only  partially  specified.  Their 
signature  is  as  described  above,  and  they  are  constrained  to  preserve  an  appropriately  defined 
well-formedness  property.  Otherwise,  they  are  unconstrained.  In  particular,  the  semantics  of 
their  operations  is  immaterial  to  our  discussion.  In  this  paper,  we  are  concerned  only  With 
whether  the  entire  generic  database  is  serially  correct  for  non-orphans,  in  which  case  the  various 
algorithms  presented  earlier  guarantee  the  transformed  system  is  serially  correct  for  all 
transaction  names.  The  problem  of  ensuring  that  specific  generic  systems  are  serially  correct  for 
non-orphans  is  addressed  elsewhere  [4], 
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9.1.1.  Generic  Actions  and  Well-Formedness 

For  a  generic  system,  we  extend  the  object  mapping  as  follows.  Define  object(rc)  =  X  if  7t  is  an 
INFORM j:OMMIT_AT(X)OF(T)  or  INFORM_ABORT_AT(X)OF(T)  action.  We  define  the 
generic  actions  to  be  the  serial  actions,  plus  the  INFORM_COMMIT  and  INFORM_ABORT 
actions. 

Now  we  define  “generic  object  well-formedness.”  Let  X  be  any  object  name.  A  sequence  P 
of  generic  actions  n  with  object(rt)  =  X  is  defined  to  be  generic  object  well-formed,  for  X 
provided  that  the  following  conditions  hold. 

1.  There  is  at  most  one  CREATE(T)  event  in  p  for  any  transaction  T. 

2.  There  is  at  most  one  REQUEST_COMMIT  event  in  P  for  any  transaction  T. 

3.  If  there  is  a  REQUEST_COMMIT  event  for  access  transaction  T  in  P,  then  there  is 
a  preceding  CREATE(T)  event  in  p. 

4.  There  is  no  transaction  T  for  which  both  an  INFORM_COMMIT_AT(X)OF(T) 
event  and  an  INFORM_ABORT_AT(X)OF(T)  event  occur. 

5.  If  an  ENFORM_COMMIT_AT(X)OF(T)  event  occurs  in  p  and  T  is  an  access  to  X, 
then  there  is  a  preceding  R£QUEST_COMMIT  event  for  T. 

The  following  simple  lemma  shows  a  connection  between  transaction  well-formedness  for 
accesses  and  generic  object  well-formedness. 

Lemma  32:  Suppose  P  is  a  sequence  of  generic  actions  k  with  object(tt)  =  X.  If  p  is 

generic  object  well-formed  for  X  and  T  is  an  access  to  X,  then  piT  is  transaction  well- 

formed  for  T. 

9.1.2.  Generic  Object  Automata 

A  generic  object  automaton  G  for  an  object  name  X  is  an  I/O  automaton  with  the  following 
external  action  signature. 

Input: 

CREATE(T),  for  T  an  access  to  X 

INFORM_COMMIT_AT(X)OF(T),  for  T  any  transaction  name 

INFORM_ABORT_AT(X)OF(T),  forT  any  transaction  name 

Output: 

REQUEST_COMMIT(T,v),  for  T  an  access  to  X  and  v  a  value 

In  addition,  G  may  have  an  arbitrary  set  of  internal  actions.  G  is  required  to  preserve  generic 
object  well-formedness.  Except  for  this  well-formedness  requirement,  generic  object  automata 
can  be  chosen  arbitrarily. 

Generic  objects  are  similar  to  the  abstract  objects  of  Argus  and  other  “object-oriented” 
systems.  A  generic  object  provides  a  set  of  accesses  through  which  other  transactions  can 
observe  and  change  the  object’s  state.  (These  accesses  can  be  thought  of  as  instances  of  the 
“operations”  usually  assumed  for  objects  in  object-oriented  systems.)  Accesses  can  be  invoked 
by  concurrent  transactions,  and  transactions  can  abort;  thus,  in  generic  transaction-processing 
systems  that  guarantee  serial  correctness,  generic  objects  must  provide  synchronization  and 
recovery.  The  objects  studied  in  [13,  12],  which  use  an  exclusive  locking  variation  of  Moss’s 
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algorithm  [18]  for  synchronization  combined  with  version  stacks  fcr  recovery,  are  examples  of 
generic  objects  that  provide  synchronization  and  recovery  sufficient  to  ensure  serial  correctness 
for  non-orphans.  Similarly,  the  more  general  objects  studied  in  [4],  which  use  a  commutativity- 
based  locking  algorithm  that  permits  concurrent  updates,  are  also  generic  objects  that  ensure 
serial  correctness  for  non-orphans. 

9.1.3.  Generic  Controller 

The  third  kind  of  component  in  a  generic  system  is  the  generic  controller.  The  generic 
controller  is  also  modeled  as  an  I/O  automaton.  The  transactions  and  generic  objects  have  been 
specified  to  be  any  automata  whose  actions  and  behavior  satisfy  certain  simple  syntactic 
restrictions.  A  generic  controller,  however,  is  a  fully  specified  automaton,  particular  to  each 
system  type.  (Recall  that  we  have  assumed  that  the  system  type  is  fixed;  we  describe  the  generic 
controller  for  the  fixed  system  type.) 

The  generic  controller  passes  requests  for  the  creation  of  subtransactions  to  the  appropriate 
recipients,  makes  decisions  about  the  commit  or  abort  of  transactions,  passes  reports  about  the 
completion  of  children  back  to  their  parents,  and  informs  objects  of  the  fate  of  transactions.  It 
allows  concurrency  and  aborts,  and  leaves  the  task  of  coping  with  them  to  the  generic  objects. 

The  generic  controller  is  a  very  nondeterministic  automaton.  It  may  delay  passing  requests  or 
reports  or  making  decisions  for  arbitrary  lengths  of  time,  and  may  decide  at  any  time  to  abort  a 
transaction  whose  creation  has  been  requested  (but  that  has  not  yet  completed).  The  generic 
controller  can  be  implemented  in  many  different  ways  by  controllers  that  make  specific  choices 
from  among  the  many  nondeterministic  possibilities.  For  instance.  Moss  [18]  describes  a 
distributed  implementation  of  the  generic  controller  that  copes  with  node  and  communication 
failures  yet  still  commits  a  subtransaction  whenever  possible.  Our  results  apply  a  fortiori  to  all 
implementations  of  the  generic  controller  obtained  by  restricting  the  nondeterminism. 

The  generic  controller  has  the  following  action  signature. 

Input: 

REQUEST_CREATE(T),  T  *  T0 
REQUEST_COMMIT(T,v) 

Output: 

CREATE(T) 

COMMIT (T),  T  *  T0 
ABORT(T),  T  5=  T0 
REPORT_CCMMIT(T,v),  T  *  T0 
REPORT_ABORT(T),  T  *  TQ 
INFORM  _COMMIT_AT(X)OF(T),  T  *  T0 
INFORM_ABORT_AT(X)OF(T),  T  *  T0 

The  REQUEST_CREATE  and  REQUEST_COMMIT  inputs  are  intended  to  be  identified  with 
the  corresponding  outputs  of  transaction  and  generic  object  a  tomata,  and  correspondingly  for 
the  output  actions. 

Each  state  s  of  the  generic  controller  consists  of  six  sets:  s.create_requested,  s.created, 


s.commit_requested,  s.committed,  s.aborted  and  s.reported.  The  set  s.commit_requested  is  a  set 
of  (transaction,value)  pairs,  and  the  others  are  sets  of  transaction  names.  All  are  empty  in  the 
start  state  except  for  create_requested,  which  is  (T0}.  Define  s.completed  =  s.committed  u 
s.aborted. 

The  transition  relation  of  the  generic  controller  consists  of  exactly  those  triples  (s’,7t,s) 
satisfying  the  preconditions  and  yielding  the  effects  described  below,  where  n  is  the  indicated 
action.  We  include  in  the  effects  only  those  conditions  on  the  state  s  that  may  change  with  the 
action.  If  a  component  of  s  is  not  mentioned  in  the  effects,  it  is  implicit  that  the  set  is  the  same  in 
s’  and  s. 

REQUEST_CREATE(T),  T*T0 
Effect: 

s.create_requested  =  s’.create_requested  u  {T} 

REQUEST_COMMIT(T,v) 

Effect: 

s.commit_requested  =  s’.commit_requested  u  { (T,v) } 

CREATE(T) 

Precondition: 

T  e  s’.create_requested  -  s’. created 
Effect: 

s.created  =  s ’.created  u  {T} 

COMMIT(T),  T*T0 
Precondition: 

(T,v)  e  s’.commit_requested  for  some  v 
T  e  s ’.completed 
Effect: 

s.committed  =  s’.committed  u  {T} 

ABORT(T),  T  *  T0 
Precondition: 

T  e  s’.create-requested  -  s ’.completed 
Effect: 

s.aborted  =  s’. aborted  u  {T} 

REPORT_COMMIT (T, v) ,  T*T0 
Precondition: 

T  e  s’.committed 
(T,v)  e  s’.commit_requested 
T  €  s’. reported 
Effect: 

s.reported  =  s’. reported  u  {T} 

REPORT_ABORT(T),  T  *  T0 
Precondition: 

Te  s'  aborted 
T  «  s’. reported 
Effect: 
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s. reported  =  s’. reported  u  {T} 

INFORM_COMMIT_AT(X)OF(T),  T  *  T0 
Precondition: 

T  e  s ’.committed 

INFORM.  ABORT.AT (X)OF(T),  T  *  T0 
Precondition: 

T  €  s’. aborted 

The  generic  controller  assumes  that  its  input  actions,  REQUEST.CREATE  and 
REQUEST.COMMIT,  can  occur  at  any  time,  and  simply  records  them  in  the  appropriate 
components  of  the  state.  Once  the  creation  of  a  transaction  has  been  requested,  the  controller 
can  create  it  by  producing  a  CREATE  action.  The  precondition  of  the  CREATE  action  indicates 
that  a  given  transaction  will  be  created  at  most  once;  the  effect  of  the  CREATE  is  to  record  that 
the  creation  has  occurred.  Similarly,  the  effect  of  a  COMMIT  or  ABORT  action  is  to  record  that 
the  acdon  has  occurred.  REPORT.COMMIT,  REPORT.ABORT,  INEORM_COMMIT  and 
INFORM_ABORT  actions  can  be  generated  at  any  time  after  the  corresponding  COMMIT  and 
ABORT  actions  have  occurred.  The  precondition  for  a  COMMIT  action  ensures  that  a 
transaction  only  commits  if  it  has  requested  to  do  so,  and  it  has  not  already  completed 
(committed  or  aborted).  The  precondition  for  an  ABORT  action  ensures  that  a  transaction  will 
be  aborted  only  if  a  REQUEST.CREATE  has  occurred  for  it  and  it  has  not  already  completed. 
There  are  no  other  constraints  on  when  a  transaction  can  be  aborted,  however.  For  example,  a 
transaction  can  be  aborted  while  some  of  its  descendants  are  still  running. 

The  following  lemma  follows  easily  by  induction,  using  simple  invariants  maintained  by  the 
generic  controller.  (E.g.,  see  [4].) 

Lemma  33: 

1 .  Let  T  be  any  transaction  name.  Then  the  generic  controller  preserves 
transaction  well-formedness  for  T. 

2.  Let  X  be  any  object  name.  Then  the  generic  controller  preserves  generic 
object  well-formedness  for  X. 

3.  The  generic  controller  preserves  basic  database  well-formedness. 

9.1.4.  Generic  Database 

A  generic  database  if  the  composition  of  a  strongly  compatible  set  of  automata  indexed  by  the 
union  of  the  set  of  object  names  and  the  singleton  set  {GC}  (for  “generic  controller”). 
Associated  with  each  object  name  X  is  a  generic  object  automaton  Gx  for  X,  and  associated  with 
the  name  GC  is  the  generic  controller  automaton  for  the  system  type. 

Lemma  34:  If  (3  is  a  behavior  of  a  generic  database,  then  for  every  object  name  X, 

(3IX  is  generic  object  well-formed. 

Proof:  Let  X  be  an  object  name.  Of  the  components  of  the  generic  database,  only 
Gx  and  the  generic  controller  have  external  actions  tc  for  which  object(7t)  =  X.  The 
other  components  thus  trivially  preserve  generic  object  well-formedness  for  X.  By 
explicit  assumption,  Gx  preserves  generic  object  well-formedness  for  X,  and  by 
Lemma  33,  the  generic  controller  preserves  generic  object  well-formedness  for  X.  The 
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result  follows  from  Proposition  4.  □ 

Lemma  35:  Let  B  be  a  generic  database.  Then  B  preserves  basic  database  well- 
formedness. 

Proof:  A  simple  case  analysis.  The  only  subtle  case  is  when  prc  is  a  behavior  of  B, 
with  P  basic  database  well-formed  and  n  a  REQUEST_COMMIT(T,v)  event  for  an 
access  T  to  X.  The  argument  that  (37tlT  is  transaction  well-formed  for  T  depends  upon 
the  fact  that  p7tlX  is  generic  object  well-formed  for  X,  as  shown  in  Lemma  34.  □ 

It  follows  that  the  generic  database  is  an  example  of  a  basic  database. 

9.1.5.  Generic  Systems 

A  generic  system  is  the  composition  of  a  strongly  compatible  set  of  automata  indexed  by  the 
union  of  the  set  of  non-access  transaction  names,  the  set  of  object  names  and  the  singleton  set 
{GC}.  Associated  with  each  non-access  transaction  name  T  is  a  transaction  automaton  AT  for  T. 
Associated  with  each  object  name  X  is  a  generic  object  automaton  Gx  for  X.  Finally,  associated 
with  the  name  GC  is  the  generic  controller  automaton  for  the  system  type. 

When  the  particular  generic  system  is  clear  from  context,  we  call  its  executions,  schedules  and 
behaviors  the  generic  executions,  generic  schedules  and  generic  behaviors,  respectively. 

9.1.6.  A  Family  of  Affects  Relations 

Now  we  define  a  family  R  =  {Rp}  of  affects  relations  for  any  particular  generic  system  B.  We 
do  this  by  first  defining  a  family  R’  =  {R’p}  of  directly-affects  relations  for  B,  and  then  taking 
transitive  closures.  For  a  sequence  (3  of  generic  actions,  define  the  relation  R’p  to  be  the  relation 
containing  the  pairs  (0,7t)  of  events  such  that  0  occurs  before  k  in  p,  and  at  least  one  of  the 
following  holds: 

•  transaction^)  =  transaction(tt)  and  n  is  an  output  event  of  the  transaction, 

•  object(0)  =  object(Tt)  and  n  is  a  REQUEST_COMMIT(T,v)  event, 

•  0  is  a  REQUEST_CREATE(T)  and  tc  a  C REATE (T)  event, 

•  0  is  a  REQUEST_COMMIT(T,v)  and  k  a  COMMIT(T)  event, 

•  is  a  REQUEST_CREATE(T)  and  k  an  ABORT(T)  event, 

•  0  is  a  COMMIT (T)  and  n  a  REPORT_COMMIT(T,v)  event, 

•  0  is  an  ABORT(T)  and  n  a  REPORT_ABORT(T)  event, 

•  <(>  is  a  COMMIT(T)  and  n  an  INFORM_COMMIT_AT(X)OF(T)  event,  or 

•  0  is  an  ABORT(T)  and  7t  an  INFORM_ABORT_AT(X)OF(T)  event. 

Now  define  the  relation  Rp  to  be  the  transitive  closure  of  R’p.  It  is  easy  to  see  that  Rp  is  an 
irreflexive  partial  order. 

The  idea  is  that  0  directly  affects  n  if  they  both  occur  at  the  same  transaction  or  object  (and  n. 
is  an  output  of  the  transaction,  or  a  REQUEST_COMMIT  of  the  object),  or  if  they  involve 
different  transactions  or  objects  but  the  generic  system  will  require  0  to  occur  before  n  can  occur. 
This  notion  of  one  event  affecting  another  is  “safe,”  in  the  sense  that  0  affects  %  if  there  is  any 
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way  that  the  precondition  for  tc  could  require  0  to  have  occurred.  If  the  events  involve  different 
transactions  or  objects,  the  preconditions  for  tc  in  the  generic  controller  require  0  to  occur  if  0 
directly  affects  tc.  If  the  events  occur  at  the  same  transaction  or  object,  however,  it  might  be  that 
0  happens  to  occur  before  tc,  yet  that  the  particular  transaction  or  object  does  not  require  0  to 
occur  before  tc.  In  the  absence  of  more  information  about  the  particular  transactions  or  objects 
used  in  a  system,  however,  it  is  difficult  to  say  more  about  the  ways  in  which  one  event  can 
affect  another.  Thus,  we  make  the  “safe”  choice  of  assuming  an  effect  whenever  one  could 
occur.  Fortunately,  the  orphan  management  algorithms  described  earlier  in  this  paper  are 
essentially  independent  of  the  particular  transactions  and  objects  used  in  a  system,  and  do  not 
rely  on  more  information  about  them. 

The  next  few  lemmas  show  that  the  family  {Rg}  defined  above  is  a  family  of  affects  relations 
for  B. 

Lemma  36:  If  {5  is  a  finite  behavior  of  generic  system  B  and  y  is  an  Rg-closed 
subsequence  of  (3,  then  y  is  a  behavior  of  B. 

Proof:  For  each  non-access  transaction  name  T,  let  AT  be  the  transaction  automaton 
for  T  in  B,  and  for  each  object  name  X,  let  Gx  be  the  generic  object  automaton  for  X 
in  B.  By  Proposition  2,  it  suffices  to  show  that  ylT  is  a  behavior  of  AT  for  all  non- 
access  transaction  names  T,  that  yiX  is  a  behavior  of  Gx  for  all  object  names  X,  and 
that  y  is  a  behavior  of  the  generic  controller.  We  show  these  in  turn. 

First,  suppose  that  T  is  a  non-access  transaction  name.  If  ylT  contains  no  output 
events  of  AT,  then  the  input-enabling  property  implies  that  ylT  is  a  behavior  of  AT.  So 
assume  that  there  is  at  least  one  output  event  of  AT  in  ylT,  and  let  7t  be  the  last  such 
event.  Let  y*  be  the  prefix  of  y  ending  with  it.  Since  y  is  closed  in  P,  it  follows  from 
the  definition  of  Rp  that  y  contains  all  events  of  T  that  precede  tc  in  p.  Thus,  y’lT  is  a 
prefix  of  pIT  and  so  is  a  behavior  of  AT.  Since  ylT  differs  from  y’lT  only  by  the 
possible  inclusion  of  some  final  input  events  of  AT,  the  input-enabling  property 
implies  that  yiT  is  a  behavior  of  AT. 

A  similar  argument  shows  that  if  X  is  an  object  name,  then  ylX  is  a  behavior  of  Gx. 

Now  we  show  that  y  is  a  behavior  of  the  generic  controller.  Note  that  the  generic 
controller  is  deterministic  in  the  sense  that  for  a  given  state  s’  and  action  tc,  there  is  at 
most  one  state  s  such  that  (s’,7t,s)  is  a  step  of  the  generic  controller.  We  proceed  by 
induction  on  the  lengths  of  prefixes  5  of  y.  The  basis,  where  the  length  of  8  is  0,  is 
obvious.  So  suppose  that  5  =  8’tc,  where  tc  is  a  single  event.  Let  P’tc  be  the  prefix  of  P 
ending  with  tc.  We  consider  cases,  showing  in  each  case  that  tc  is  enabled  after  5’. 

1.  tc  =  CREATE(T) 

Then  Lemma  35  and  Proposition  5  imply  that  REQUEST_CREATE(T) 
occurs  in  p’,  and  no  CREATE(T)  occurs  in  p’.  Since  y  is  Rg-closed  in  P, 
REQUEST_CREATE(T)  also  occurs  in  5’.  Similarly,  no  CREATE(T)  occurs 
in  8’.  If  follows  that  tc  is  enabled  in  the  (unique)  state  in  which  8’  can  leave 
the  generic  controller.  Thus,  tc  is  enabled  after  8’. 
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2. k  =  COMMIT(T) 

Then  Lemma  35  and  Proposition  5  imply  that  P’  contains 
REQUEST_COMMIT(T,v)  and  contains  no  completion  events  for  T.  Since  y 
is  Rp-closed  in  P,  8’  contains  REQUEST_COMMIT(T,v),  and  does  not 
contain  a  completion  event  for  T.  It  follows  that  n  is  enabled  after  8’. 

3.  n  =  ABORT(T) 

Then  P’  contains  REQUEST_CREATE(T)  and  contains  no  completion  events 
for  T,  so  8’  contains  REQUEST_CREATE(T)  and  no  completion  events  for 
T.  Thus,  K  is  enabled  after  8’. 

4.  %  =  REPORT_COMMIT(T,v) 

Then  P’  contains  COMMIT(T)  and  REQUEST_COMMIT(T,v),  and  contains 
no  report  events  for  T.  Therefore,  the  same  is  true  of  8’,  so  k  is  enabled  after 
8’. 

5.  jt  =  REPORT_ABORT(T) 

Similar  to  the  preceding  arguments. 

6.  K  =  INFORM_COMMIT_AT(X)OF(T) 

Similar  to  the  preceding  arguments. 

7.  re  =  INFORM  J20MMIT_AT(X)0F(T) 

Simu lt  to  the  preceding  arguments. 


□ 

Lemma  37:  The  family  {Rp }  is  a  family  of  affects  relations  for  B. 

Proof:  The  first  two  properties  of  families  of  affects  relations  are  immediate  from 
the  definition  of  {Rp}.  The  third  property  is  proven  in  the  lemma  above. 

The  fourth  property  requires  that  whenever  an  ABORT(T)  event  <}>  affects  an  event  n 
of  certain  types,  there  is  a  specific  type  of  intervening  event  \|/  that  is  also  affected  by 
<(>.  To  see  that  this  property  is  satisfied,  note  that  Rp  is  defined  as  the  transitive  closure 
of  the  directly-affects  relation  R’p.  Each  type  of  event  7t  of  interest  is  only  directly 
affected  by  earlier  events  that  satisfy  the  restrictions  on  \jr.  Thus,  if  n  is  affected  by  <J), 
it  must  be  so  affected  by  the  transitive  closure  over  a  chain  of  directly-affects  relations 
in  which  an  event  \| /  of  the  appropriate  type  occurs.  □ 

9.1.7.  Applying  Orphan  Management  Algorithms  to  Generic  Systems 
Since  we  have  shown  that  generic  systems  are  instances  of  basic  systems,  and  that  the  directly- 
affects  relation  we  defined  above  generates  a  family  of  affects  relations,  we  may  apply  our 
general  results  for  orphan  management  algorithms  to  generic  systems.  Before  we  state  these 
results,  we  illustrate  one  orphan  management  transformation  by  describing  explicitly  the  steps  of 
the  system  obtained  by  applying  the  Argus  algorithm  to  a  generic  system. 

If  B  is  a  generic  system  and  R’p  is  the  family  of  directly-affects  relations  given  above,  then  the 
steps  of  Argus(B,R’p)  are  defined  as  follows. 

•  (s’.basic_state,rc,s.basic_state)  is  a  step  of  the  generic  database. 

•  s. history  =  s’.historyrc  if  it  is  a  basic  action. 

•  s.history  =  s’. history  if  k  is  not  a  basic  action. 
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•  If  0  *  k,  then  s.known_aborts(0)  =  s’.known_aborts(0). 

•  If  k  is  a  REQUEST_CREATE(T)  action,  then  s,.known_aborts(4)'»  c 
s.known_dboits(,rc)  for  all-in  s',  history  such  that  transaction^)  =  parent(T). 

•  If  it  is  a  REQUEST_COMMIT(T,v)  action,  where  T  is  a  non-access  transaction 
name,  then  s’.known_aborts(0)  c  s.known_aborts(7t)  for  all-in  s’. history  such  that 
transaction^)  =  T. 

•  If  jt  is  a  REQUEST_COMMIT(T,v)  action,  where  T  is  an  access  transaction  name, 
then  s’.known_aborts(0)  c  s.known_aborts(7t)  for  ail  0  in  s’. history  such  that 
object(0)  =  object(T). 

•  If  7t  is  a  CREATE(T)  action,  then  s’.known_aborts(0)  <Z  s.known_aborts(7i)  for  all 
REQUEST_CREATE(T)  events  0  in  s’. history. 

•  If  7t  is  a  COMMIT(T)  action,  then  s’.known_aborts(0)  c  s.known_aborts(7t)  for  all 
REQUEST_COMMIT(T,v)  events  0  in  s’. history. 

•  If  7t  an  an  ABORT(T)  action,  then  s’.known_aborts(0)  c  s.known_aborts(7t)  for  all 
REQUEST_CREATE(T)  events  0  in  s’.history. 

•  If  7t  is  a  REPORT_COMMIT(T,v)  action,  then  s’.known_aborts(0)  c 

s.known_abons(rt)  for  all  COMMIT(T)  events  0  in  s’.history. 

•  If  7t  is  a  REPORT_ABORT(T)  action,  then  s’.known_aborts(0)  c 

s.known_aborts(7t)  for  all  ABORT(T)  events  0  in  s’.history,  and  T  e 

s .  known_aborts(7t) . 

•  If  7t  is  an  INFORM_COMMIT_AT(X)OF(T)  action,  then  s’.known_aborts(0)  c 
s.known_aborts(7t)  for  all  COMMIT(T)  events  0  in  s’.history. 

•  If  7t  is  an  INFORM_ABORT_AT(X)OF(T)  action,  then  s’.known_aborts(0)  £ 

s.known_aborts(7t)  for  all  ABORT(T)  events  0  in  s’.history,  and  T  e 

s .  known_aborts(7t) . 

•  If  k  is  a  REQUEST_COMMIT(T,v)  action  for  an  access  T  to  object  X,  then  there  is 
no  ancestor  of  T  in  s’.known_aborts(0),  for  any  event  0  of  object  X  in  s’.history. 

The  filtered  database  uses  global  information  about  the  history  to  prevent  the 
REQUEST_COMMIT  of  an  access  from  occurring  if  it  would  be  affected  by  an  ABORT  of  an 
ancestor.  The  Argus  database  uses  more  local  information,  which  is  obtained  by  propagating  the 
known_aborts  sets  from  each  event  to  any  later  events  that  it  directly  affects.  For  example, 
consider  the  application  above  of  the  Argus  algorithm  to  a  generic  database.  The  known_aborts 
set  for  a  REQUEST_CREATE(T)  action  is  obtained  from  the  known_aborts  sets  for  all 
preceding  events  at  parent(T).  Since  REQUEST_CREATE(T)  is  generated  by  parent(T),  the 
known_aborts  set  for  it  can  easily  be  computed  with  information  available  locally  at  parent(T) 
when  the  REQUEST_CREATE(T)  action  occurs.  A  similar  situation  arises  with 
REQUEST_COMMIT  actions,  which  are  outputs  of  transactions  and  objects.  The  other  actions, 
which  are  outputs  of  the  generic  controller,  are  directly  affected  by  exactly  one  preceding  event. 
Thus,  the  known_aborts  set  for  one  of  these  actions  can  easily  be  computed  from  the 
known_aborts  set  for  the  single  event  that  precedes  it.  For  instance,  the  known_aborts  set  for  a 
CREATE(T)  event  can  be  obtained  directly  from  the  known_aborts  set  for  the  preceding 
REQUEST_CREATE(T)  event.  If  the  two  events  occur  at  the  same  site  in  a  network,  this 


45 


information  would  be  available  locally;  if  they  occur  at  different  sites,  it  could  be  sent  in  the 
message  used  to  transmit  the  REQUEST_CREATE  event  to  the  site  that  performs  the  CREATE 
event. 

The  following  corollary  shows  that  the  Argus  algorithm  and  the  clocked  algorithm  from  [16] 
can  both  be  used  for  a  generic  system: 

Corollary  38:  Let  B  be  a  generic  system,  and  R  and  R’  the  family  of  affects  and 
directly-affects  relations  defined  above.  If  B  is  serially  correct  for  non-orphans,  then 
the  following  are  true: 

•  Filtered(B,R)  is  serially  correct. 

•  Argus(B,R’)  is  serially  correct. 

•  Strictly-Filtered(B)  is  serially  correct. 

•  Clocked(B)  is  serially  correct. 


9.2.  Pseudotime  Systems 

The  essential  feature  of  systems  using  timestamps  is  the  explicit  construction  of  a  sibling  order 
representing  the  intended  serialization  of  an  execution.  This  order  is  represented  in  terms  of 
intervals  of  pseudotime,  an  arbitrarily  chosen  totally  ordered  set.  Formally,  we  let  /'be  the  set  of 
pseudotimes,  ordered  by  <.  We  represent  pseudotime  intervals  as  half-open  intervals  [p,q)  in  P, 
and  refer  to  them  using  capital  letters.  If  P  =  [p,q),  then  we  write  Pmin  for  p  and  Pmax  for  q.  If  P 
and  Q  are  intervals  of  pseudotime,  we  write  P  <  Q  if  Pmax  <  Qmin.  Clearly,  if  P  <  Q,  then  P  and 
Q  are  disjoint. 

A  pseudotime  system  consists  of  a  collection  of  transaction  automata,  one  for  each  non-access 
transaction  name,  a  collection  of  “pseudotime  object  automata,”  one  for  each  object  name,  and 
a  single  “pseudotime  controller  automaton.”  The  interactions  between  the  components  are  as 
follows.  The  transaction  interface  is  exactly  as  before.  A  pseudotime  object  automaton  for  X 
has  the  same  actions  as  a  generic  object  automaton,  with  the  addition  of 
INFORM_TIME_AT(X)OF(T,p)  input  actions  to  inform  the  object  that  pseudotime  p  has  been 
assigned  to  an  access  transaction  T.  The  pseudotime  controller  has  the  same  actions  as  the 
generic  controller,  with  the  addition  of  INFORM_TIME_AT(X)OF(T,p)  output  actions  (for 
access  transactions  T)  and  ASSIGN_PSEUDOTIME(T,P)  output  actions  (for  all  transactions  T) 
by  which  the  controller  assigns  the  pseudotime  range  P  to  transaction  T. 

9.2.1.  Pseudotime  Actions  and  Well-formedness 

The  object  mapping  for  a  pseudotime  system  is  the  same  as  that  for  a  generic  system,  with  the 
addition  that  we  define  object(Tt)  =  X  if  7t  is  an  INFORM_TIME_AT(X)OF(T,p)  action.  We 
define  the  pseudotime  actions  to  be  the  generic  actions,  plus  the  INFORM_TIME  and 
ASSIGN_PSEUDOTIME  actions. 

Now  we  define  “pseudotime  object  well-formedness.”  Let  X  be  any  object  name.  A 
sequence  of  pseudotime  actions  k  with  object(rc)  =  X  is  defined  to  be  pseudotime  object 
well-formed  for  X  provided  that  the  following  conditions  hold. 

1 .  There  is  at  most  one  CREATE(T)  event  in  (3  for  any  transaction  T. 
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2.  There  is  at  most  one  REQUEST_COMMIT  event  in  [3  for  any  transaction  T. 

3.  If  there  is  a  REQUEST_COMMIT  event  for  T  in  p,  then  there  is  a  preceding 
CREATF(T)  event  and  also  a  preceding  INFORM_TTlE_AT(X)Or(T,p)  in  p. 

4.  There  is  no  transaction  T  for  which  there  are  two  different  pseudotimes,  p  and  p\ 
such  that  INFORM_TIME_AT(X)OF(T,p)  and  INFORM_TIME_AT(X)OF(T,p’) 
both  occur  in  p. 

5.  There  is  no  pseudotime  p  for  which  there  are  two  different  transactions,  T  and  T\ 
such  that  INFORM_TIME_AT(X)OF(T,p)  and  INFORM_TIME_AT(X)OF(T\p) 
both  occur  in  p. 

6.  There  is  no  transaction  T  for  which  both  an  INFORM_COMMIT_AT(X)OF(T) 
event  and  an  INFORM_ABORT_AT(X)OF(T)  event  occur. 

7.  If  an  INFORM_COMMIT_AT(X)OF(T)  event  occurs  in  P  and  T  is  an  access  to  X, 
then  there  is  a  preceding  REQUEST_COMMIT  event  for  T. 

9.2.2.  Pseudotime  Object  Automata 

A  pseudotime  object  automaton  P  for  an  object  name  X  is  an  I/O  automaton  with  the  following 
external  action  signature. 

Input: 

CREATE(T),  T  an  access  to  X 
INFORM_COMMIT_  AT  (X)OF(T) 

INFORM_ABORT_AT(X)OF(T) 

INFORM_TIME_AT(X)OF(T,p),  T  an  access  to  X,  p  6  P 

Output: 

REQUESTCOMMIT(T,v),  T  an  access  to  X 

In  addition,  P  may  have  an  arbitrary  set  of  internal  actions.  P  is  required  to  preserve 
pseudotime  object  well-formedness. 

9.2.3.  Pseudotime  Controller 

The  pseudotime  controller  guarantees  that  siblings  are  assigned  disjoint  intervals  of 
pseudotime,  and  that  each  transaction’s  interval  is  a  subset  of  that  of  its  parent.  The  pseudotime 
controller  has  the  actions  of  the  generic  controller  together  with  an  extra  class  of  output  actions 
ASSIGN_PSEUDOTIME(T,P)  for  T  5*  Tq  and  P  a  pseudotime  interval.  The  purpose  of  the 
ASSIGN_PSEUDOTIME  actions  is  to  construct,  at  run-time,  a  sibling  order  that  specifies  the 
apparent  serial  ordering  of  transactions.  Also,  there  is  an  extra  class  of  actions 
INFORM_TIME_AT(X)OF(T,p)  for  access  transactions  T.  A  state  s  of  the  pseudotime 
controller  has  the  same  components  as  a  state  of  the  generic  controller  together  with  an 
additional  component  s. interval,  which  is  a  partial  function  from  T  to  the  set  of  pseudotime 
intervals.  In  the  initial  state  s0  of  the  pseudotime  controller  s0.interval  =  {(Tq,Pq)}  for  some 
pseudotime  interval  Pq,  and  all  other  components  are  as  in  the  initial  state  of  the  generic 
controller. 


The  transition  relation  for  generic  actions  is  the  same  as  that  for  the  generic  controller,  except 
that  the  actions  CREATE(T)  and  ABORT(T)  have  an  additional  precondition:  T  e 
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domains’. interval).  The  additional  actions  are  determined  as  follows. 

ASSIGN_PSEUDOTIME(T,P) 

Precondition: 

i  e  s'.create-requested 
T  e  domain  (s’. interval) 

P  c  s’.interval(parent(T)) 

P  >  s’.interval(T’)  for  every  T’  in  siblings(T)  n  domain(s ’.interval) 

Effect: 

s. interval  =  s ’.interval  u  {(T,P)} 

INFORM_TIME_AT(X)OF(T,p),  T  an  access  to  X 
Precondition: 

(T,P)  e  s’. interval 

P  ~  ^min 

The  following  lemma  is  straightforward. 

Lemma  39: 

1.  Let  T  be  any  transaction  name.  Then  the  pseudotime  controller  preserves 
transaction  well-formedness  for  T. 

2.  Let  X  be  any  object  name.  Then  the  pseudotime  controller  preserves 
pseudotime  object  well-formedness  for  X. 

3.  The  pseudotime  controller  preserves  basic  database  well-formedness. 

9.2.4.  Pseudotime  Database 

A  pseudotime  database  is  the  composition  of  a  strongly  compatible  set  of  automata  indexed  by 
the  union  of  the  set  of  object  names  and  the  singleton  set  {PC}  (for  “pseudotime  controller”). 
Associated  with  each  object  name  X  is  a  pseudotime  object  automaton  Px  for  X.  Finally, 
associated  with  the  name  PC  is  the  pseudotime  controller  automaton  for  the  system  type. 

Lemma  40:  If  (3  is  a  behavior  of  a  pseudotime  database,  then  for  every  object  name 
X,  piX  is  pseudotime  object  well-formed. 

Lemma  41:  Let  B  be  a  pseudotime  database.  Then  B  preserves  basic  database  well- 
formedness. 

It  follows  that  the  pseudotime  database  is  an  example  of  a  basic  database. 

9.2.5.  Pseudotime  Systems 

A  pseudotime  system  is  the  composition  of  a  strongly  compatible  set  of  automata  indexed  by 
the  union  of  the  set  of  non-access  transaction  names,  the  set  of  object  names  and  the  singleton  set 
{PC}.  Associated  with  each  non-access  transaction  name  T  is  a  transaction  automaton  Aj  for  T. 
Associated  with  each  object  name  X  is  a  pseudotime  object  automaton  Px  for  X.  Finally, 
associated  with  the  name  PC  is  the  pseudotime  con,  ■•oiler  automaton  for  the  system  type. 

When  the  particular  pseudotime  system  is  clear  from  context,  we  call  its  executions,  schedules 
and  behaviors  the  pseudotime  executions,  pseudotime  schedules  and  pseudotime  behaviors, 
respectively. 
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9.2.6.  A  Family  of  Affects  Relations 

Now  we  define  a  family  R  =  {Rp >  of  affects  relations  for  any  particular  pseudotime  system  B. 
We  do  this  by  first  defining  a  family  R’  =  {R’p}  of  chrectly-affects  relations  for  B,  and  then 
taking  transitive  closures.  For  a  sequence  (3  of  pseudotime  actions,  define  the  relation  R’p  to  be 
the  relation  containing  the  pairs  (0,  x)  of  events  such  that  0  occurs  before  n  in  (3,  and  at  least  one 
of  the  following  holds: 

•  transaction^)  =  transaction(jt)  and  n  is  an  output  event  of  the  transaction, 

•  object(0)  =  object(^)  and  x  is  a  REQUEST_COMMIT(T,v)  event, 

•  0  is  a  REQUEST_CREATE(T)  and  71  an  ASSIGN_PSEUDOTIME(T,P)  event, 

•  0  is  an  ASSIGN J>SEUDOTIME(T,P)  and  x  a  CREATE (T)  event, 

•  0  is  a  REQUEST_COMMIT(T,v)  and  7t  a  COMMIT(T)  event, 

•  0  is  a  REQUEST_CREATE(T)  and  7t  an  ABORT(T)  event, 

•  0  is  an  ASSIGN_PSEUDOTIME(T,P)  and  K  an  ABORT(T)  event, 

•  0  is  a  COMMIT(T)  and  7t  a  REPORT_COMMIT(T,v)  event, 

•  0  is  an  ABGRT(T)  and  x  a  REPORT_ABORT(T)  event, 

•  0  is  a  COMMIT(T)  and  7t  an  INFORM_COMMIT_AT(X)OF(  f)  event, 

•  0  is  an  ABORT (T)  and  n  an  INFORM_ABORT_AT (X)OF(T)  event,  or 

•  0  is  an  ASSIGN_PSEUDOTTME(T,P)  event  ana  7t  an 
LNTORM_TIME_AT(X)OF(T,p)  event. 

Once  again,  define  the  relation  Ro  to  be  the  transitive  closure  of  R’p.  It  is  easy  to  see  that  Rp 
is  an  irreflexive  partial  order.  We  claim  that  the  family  {Rp}  defined  above  is  a  family  of  affects 
relations  for  G. 

Lemma  42:  If  {3  is  a  behavior  of  pseudotime  system  B  and  y  is  an  Rp-closed 
subsequence  of  [3,  then  y  is  a  behavior  of  B. 

Proof:  Analogous  to  the  proof  of  Lemma  36.  □ 

Lemma  43:  The  family  {Rp}  is  a  family  of  affects  relations  for  B. 

9.2.7.  Applying  Orphan  Management  Algorithms  io  Pseudotime  Systems 

The  following  easy  corollary  shows  that  the  Argus  algorithm  and  the  clocked  algorithm 
from  [  1 6]  can  both  be  used  for  a  pseudotime  system: 

Corollary  44:  Let  B  be  a  pseudotime  system,  and  R  and  R’  the  family  of  affects  and 
directly-affects  relations  defined  above.  If  B  is  serially  correct  for  non-orphans,  then 
the  following  are  true: 

•  Filtered(B,R)  is  serially  correct. 

•  Argus(B,R’)  is  serially  correct. 

•  Strictly-Filtered(B)  is  serially  correct. 

•  Ciocked(B)  is  serially  correct. 
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10.  Conclusions 

We  have  defined  correctness  properties  for  orphan  management  algorithms,  and  have 
presented  precise  descriptions  and  proofs  for  two  algorithms  from  [9]  and  [16].  Our  proofs  are 
quite  simple,  and  show  that  the  systems  exhibit  a  substantial  degree  of  modularity:  the  orphan 
management  algorithms  can  be  used  in  combination  with  any  concurrency  control  protocol  (in 
basic  system  form)  that  is  serially  correct  for  non-orphans.  The  simplicity  of  our  proofs  is  a 
direct  result  of  this  modularity,  and  is  in  sharp  contrast  to  earlier  work  [6],  in  which  the  orphan 
management  algorithm  and  the  concurrency  control  protocol  were  not  cleanly  separated. 

Our  proofs  have  an  interesting  structure.  We  first  define  a  simple  abstract  algorithm  that  uses 
global  information  about  the  history  of  the  system,  and  show  that  it  ensures  that  orphans  see 
consistent  views.  We  then  formalize  the  Argus  algorithm  and  the  clocked  algorithm  in  a  way 
that  only  requires  the  use  of  local  information,  and  show  that  each  simulates  the  more  abstract 
algorithm.  The  simulation  proofs  are  quite  simple,  and  do  not  require  re-proving  the  properties 
already  proved  for  the  abstract  algorithm.  The  correctness  of  the  Argus  and  clocked  algorithm* 
then  follows  directly  from  the  correctness  of  the  abstract  algorithm. 

In  this  paper  we  have  analyzed  only  orphans  that  result  from  aborts  of  transactions.  Interesting 
algorithms  have  also  been  developed  for  detecting  and  eliminating  orphans  arising  from 
crashes  [9, 16].  These  algorithms  seem  more  complicated  than  the  algorithms  for  handling 
aborts.  An  open  question  is  whether  the  known  algorithms  for  handling  crash  orphans  can  be 
analyzed  using  techniques  similar  to  those  in  this  paper.  In  particular,  it  would  be  nice  to  find  a 
similar  separation  of  concerns  for  those  algorithms,  so  that  the  crash-orphan  algorithms  can  be 
understood  independently  of  concurrency  control  protocols  and  abort-orphan  algorithms. 
Whether  this  will  be  possible  is  still  unknown. 
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